That’s a right question. For simplicity let me provide one related example:
We have shared queries - because domains want to preload things defined in other domain. Or sql-join with them. While subquery is defined inside domain A, it becomes part of the query in domain B and now domain B should also take care of initializing virtual field defaults. As result I need to put dynamic defaults in every domain that generates my struct indirectly via query.
And we can easily have dozens of functions that creates your struct directly or indirectly in a single domain of our big monolith.
Could throw together a custom credo check that warns on %Struct{...} when Struct.new/build is detected, perhaps. A community consensus on new vs build could be handy as well.
Author of Craft GraphQL APIs in Elixir with Absinthe
Yes. For me the split I’m observing comes down to people who feel that code which calls functions should be a function call, and this proposal where doing literal syntax is actually sometimes a way to call functions dynamically. You can tell from this framing which side I’m on I suppose lol.
But more seriously some of the objections to using new such as the time required to convert code base don’t hold water. Sure we are talking about dynamic data now but what about invariants? Should struct literal syntax also run validators on the values? The answer is: no, we already crossed this bridge with changesets. (And no the type system won’t solve this, there are invariants not amenable to types).
If we had a convention around new or build then this would be a non issue. You wouldn’t have 100 spots in your code to refactor you’d have 100 function calls and you make one change to the function. This is already what you have when using changesets.
I agree with everyone who has said that “it takes to long to refactor” is not a very compelling argument. It would be nice if there was a more “blessed” constructor pattern though. It would be great to know that if I am initializing a struct I can/should always call `new` or whatever. Even better if it came with a way to prevent “private” fields from being set somehow…
These are exactly my thoughts. This entire thread wouldn’t be needed if constructors were the default way to create structs.
I’m convinced that it’s perfectly fine to have constructor functions that only pass the data into a struct. Some will become more complex later, others will stay trivial, but the changes will never spread outside of the module.
FWIW, the aforementioned estructura provides coerce/3 which calculates (also coerces and validates btw) everything because it goes through Access which is amending the calculated fields. Example.
There are none, if we use dependent types. Sorry for nitpicking, but inventing new wheels for a wheelchair, like ad-hoc validations. would never cover SMT-solving theories. Ad-hoc validations are extremely hard to validate in the wild, unlike a proof in languages like Idris. That’s basically why I started Cure effort.
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”.
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.
My latest proposal is not about %MakeMeDynamic{} anymore.
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.
You sparked a really good discussion. Thanks for that.
The fact that default: DateTime.utc_today() is resolved at compile time actually also a surprise of a similar level.
True, but that is really part of the language. It’s like the @tag that also gets evaluated at compile time.
You are right that you could learn this too. The difference is that, once you have learned ot, you don’t get surprises, whereas for your structs I would need to check the focumentation every time. This is the kind of surprise I’m talking about.
As a language you need to be conservative when adding new features to the language (consider the Change Event Horizon). Hence we ahould ask ourselves how common your problem is, and whether it could be solved on a different level before solving it on the language. Here some options I could see:
Solve the problem on a database level, e.g. at database insertion/retrieval time (and I think that would be cleanest, because you solve the problem locally)
Add a feature to Ecto that allows the initialization of default/calculated values. Maybe an _init: &myinit/1 field in your struct?
Even though I might be against your proposal, I very much appreciate you taking the time to raise it. As more use cases surface, the more likely it is that a solution might happen on a language level.
Side note:
If even creators of Ecto (and ExMachina) fell into the trap
It’s up to them to decide that. As demonstrated above there are plenty of ways on how you can extend keep things extendable. And at the end it’s always a) a balancing act and b) a learning process
