Runtime-calculated default values for structs

[ffloyd]

@tfwright

I agree with everyone who has said that “it takes to long to refactor” is not a very compelling argument.

I feel you. Such refactoring wasn’t painful for me until I started working on 2M+ LOC Elixir codebase. It’s one of the biggest (if not the biggest) production monolith written in Elixir. In any other codebase I touched, this problem was in “meh, annoying!” category, not “it’s too long to refactor”.

@Sorc96

This entire thread wouldn’t be needed if constructors were the default way to create structs.

100% percent agree! That’s the problem I’m trying to actually solve! Bear with me:

The reality I see is that %Schema{} syntax is used to “create struct with defaults”. My strongest proof that even Ecto does it and proposes it. If Ecto were enforcing using Schema.build(...) as the idiomatic way to create a schema instance - it would have dynamic defaults already.

I believe that allowing static defaults in struct definition was a design mistake (that was done for Erlang records, structs merely repeat it). If setting static default were require making a build/new function - Ecto would have build/new functions enforced.

It made me think about making %Schema{} a full-featured constructor. But it violates %A{} == %A{}, so, not a good way.

@benwilson512

Should struct literal syntax also run validators on the values?

My latest proposal is not about %MakeMeDynamic{} anymore.

@benwilson512

If we had a convention around new or build then this would be a non issue.

Not exactly. What I’m fighting with right now is the idea that static and dynamic defaults should be implemented in different ways. Ideally, all my problems would be solved by:

Remove ability to set static defaults. Any kind of defaults should require implementing new/build function.

But it’s too late for this proposal.

Should I make a proposal to Ecto then? To make Ecto create build function when defining schema and suggest people to use it over %Schema{} syntax if they need any kind of defaults? It’s a breaking change. How would you estimate chances that people agree on this? (Considering that in the most cases lack of dynamic defaults are not super painful)

Not every Elixir developer uses Ecto. And the design mistake of not enforcing usage of build/new when a struct can have dynamic defaults has a good chance to be repeated in other libraries.

That’s why I want to solve this problem on the language syntax level. It’s more bulletproof solution than relying on traditions and conventions.

My latest proposal is

@ffloyd

What about having a slightly different data-type then: dynamically created struct. It will work just like normal structs, support struct!(...), protocols, etc. The only difference is that you define it using defdynstruct and cannot create them as literal, you must use something like %MyStruct() and %MyStruct(collectable) to instantiate them?

Also, %MyStruct(...) should work for normal structs also.

(Yes, we already have struct! and can use this instead of %MyStruct(...), but it feels like worse UX to me).

Then:

• Static defaults via defstruct:
  • part of a struct definition
  • guaranteed to be applied
  • introducing the first static default does not require refactoring
• Dynamic defaults via defdynstruct:
  • part of a struct definition
  • guaranteed to be applied (you cannot do %MyStruct{})
  • introducing the first dynamic default requires refactoring, but more trivial one:
    • in the struct it’s a mere replacement of defstruct with defdynstruct
    • in the code you own it’s a mere replacement of %MyStruct{...} to %MyStruct(...)
    • in libraries: you only need to switch to using struct!(...) in places where you work with user-provided structs and avoid do %unquote(struct_mod){} hacks in macro.