Elm best practices - enforce noninstantiability with a private constructor Page

Item 4: Elm Best Practices - Enforce noninstantiability with a private constructor

In object-oriented programming languages, enforcing noninstantiability (preventing a class from being instantiated) is often done using private constructors. However, Elm is a purely functional language without classes, constructors, or mutable state. Instead, the concept of noninstantiability in Elm can be enforced through careful design patterns that prevent certain types from being instantiated or used improperly.

Understanding Noninstantiability in Elm

In Elm, noninstantiability typically means ensuring that a particular module or type cannot be instantiated or used in ways that are unintended. This is particularly useful when you want to create a module that provides only functions or constants, without allowing the creation of new instances of a particular type.

Using Modules to Enforce Noninstantiability

One way to enforce noninstantiability in Elm is by using modules to restrict access to certain types or functions. By keeping certain types or constructors private within a module, you can ensure that they cannot be instantiated outside of that module.

### Example 1: Restricting Type Constructors in a Module

```elm
module Safe exposing (SafeType, createSafeType, getValue)

-- Define a type with a private constructor
type SafeType
= SafeConstructor String

-- Provide a function to create instances
createSafeType : String -> SafeType
createSafeType value =
SafeConstructor value

-- Provide a function to extract the value
getValue : SafeType -> String
getValue (SafeConstructor value) =
value
```

In this example, the `SafeType` type has a private constructor `SafeConstructor` that is not exposed outside of the `Safe` module. The only way to create an instance of `SafeType` is through the `createSafeType` function, which allows you to enforce specific rules or validations during instantiation.

Using Singleton Patterns to Prevent Instantiation

Another approach to enforce noninstantiability is by using singleton patterns. If your goal is to prevent multiple instances of a type, you can enforce this by defining a single instance and making it the only way to access the type.

### Example 2: Enforcing Singleton Behavior

```elm
module Logger exposing (Logger, getLogger, log)

-- Define a type with a private constructor
type Logger
= LoggerInstance

-- Define a singleton instance
singletonLogger : Logger
singletonLogger =
LoggerInstance

-- Provide a function to access the singleton instance
getLogger : Logger
getLogger =
singletonLogger

-- Function to log messages
log : Logger -> String -> String
log LoggerInstance message =
"LOG: " ++ message
```

In this example, the `Logger` type has a single instance `singletonLogger` that is created and made accessible through the `getLogger` function. Since the `LoggerInstance` constructor is private, no other instances of `Logger` can be created, ensuring that `Logger` behaves as a singleton.

Using Phantom Types to Prevent Certain Instantiations

Phantom types in Elm can also be used to prevent certain instantiations by making the type system enforce constraints on how certain types are used.

### Example 3: Using Phantom Types for Noninstantiability

```elm
module Auth exposing (User, Authenticated, authenticate, getUserName)

-- Phantom type to represent authentication status
type User authStatus =
User { name : String }

-- Create an authenticated user
authenticate : String -> User Authenticated
authenticate name =
User { name = name }

-- Function to get the user name
getUserName : User Authenticated -> String
getUserName (User user) =
user.name

-- Dummy type to represent authentication status
type Authenticated
= Authenticated
```

In this example, the `User` type uses a phantom type `authStatus` to represent whether the user is authenticated. The `authenticate` function ensures that only authenticated users can be created, and the `getUserName` function requires a `User Authenticated`, preventing any unauthorized instantiation or access.

When to Enforce Noninstantiability in Elm

Enforcing noninstantiability is appropriate in Elm when:
- **Private Types**: You have types that should not be instantiated directly but only through controlled functions.
- **Singleton Patterns**: You want to ensure that only one instance of a particular type exists and is accessible throughout your application.
- **Type Safety**: You need to enforce specific constraints or states within your type system to prevent improper usage or instantiation.

Conclusion

While Elm does not have private constructors in the traditional sense, you can enforce noninstantiability through careful use of modules, singleton patterns, and phantom types. These techniques help you control how types are instantiated and used, ensuring that your application remains robust, maintainable, and free from unintended instances.