Find all the places, which need that behaviour and make them call a function setting those dynamic defaults. Anything short of that is “hope for the best / that nothing broke”. Introducing that new behaviour is no different to any other change you add to your codebase. That you consider those dynamic field values “defaults” imo doesn’t change that.
LostKobrakai
mudasobwa
Creator of Cure
Absolutely. This would have the issue with wrongly declared/used structs fixed, rather than swept it under the rug.
0
ffloyd
So, if we’re talking about a huge codebase, it means:
- do it in dozens or potentially hundreds of places (with Ecto virtual fields we need also patch each place where we read from the storage).
- do not forget to include this functionality in any new functions that create such struct (isn’t it error prone in huge projects?)
Does still look acceptable? =)
I do not agree that “introducing dynamic default” is like any other change. There is a concept of a default value. When you think about it from general design perspective “is it dynamic or not?” is an implementation detail. What I see as a problem is that static and dynamic ones has very different ways of being implemented.
Looks like you ok with the idea that “dynamic defaults should not be part of a struct definition”. It makes dynamic default an opt-in behavior, not a guaranteed one. So, we have the following inconsistency:
- Static defaults:
- part of a struct definition
- guaranteed to be applied
- introducing the first static default does not require refactoring
- Dynamic defaults:
- separate from a struct definition
- has no application guarantees (it’s up to developer to find all the places where to inject them)
- introducing the first dynamic default requires refactoring and searching for workarounds when 3rd party libraries involved.
This inconsistency is more destructive from my point of view than accepting %A{} != %A{}. If you can hint a way that will resolve this inconsistency without violating %A{} == %A{} that would be awesome.
I personally like Elixir for easiness of refactoring of business code. So argument “yes, refactoring is expensive just accept it” goes against things I love Elixir for. =)
0
LostKobrakai
I don’t think we’ll find any alignment here. I still stand by the fact that structs should behave like native datatypes, while you seem to want to make them even more a special case to what they already are and partially out of necessity. I see %Struct{} as a notation to define data and data doesn’t execute code. Yes one can change the definition of the struct, but generally people try to avoid having the before and after of those definitions meet.
Execution is btw another footgun to your proposal. %Struct{} executing code means different runtime behaviour. It’s no longer “O(1)”, but could start an http request, fail somewhere on the path and raise some arbitrary exception crashing a whole process – just from %Struct{}.
6
ffloyd
In the spirit of brainstorming:
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
defstructwithdefdynstruct - 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.
- in the struct it’s a mere replacement of
0
sodapopcan
What is the use-case around not having a dynamic values auto-generated just before insertion? I also don’t understand why would you want to have dynamically generated default values populated on read.
It would be interesting to hear motivation beyond the DateTime one. As dates go, I’m having a hard time imaging a case where you would ever want any other time than at insertion. The only thing I can think of is “when did the user start filling out this form,” though I think that could only reliably be tracked on the client.
1
ffloyd
If this question is scoped to Ecto, then:
- When a field is a subject for validation. Or part of a condition of a conditional validation. Validation happens before insertion.
- When a field is used to calculate another field value before insertion.
- When there is no persistence (virtual fields, when schema is used only for validation, like in Oban jobs).
We have a schema that resembles “booking restrictions config”. It has “current allowed dates period” virtual field. By default it should be from beginning of the current year to the end of it. Even if you read a saved one from DB.
Meanwhile, they’re cases when we need to override it. In such cases we override this virtual field.
This virtual field is used in validations. It used during rendering things for JSON responses, etc. It used in many places when the entity is used. It is very convenient to have it as a virtual field. Otherwise we need to add one additional argument/option to too many functions.
Consider that I’ve significantly simplified related business logic.
While adding this additional argument may look a right way to do, on practice it will make implementation uglier and more fragile. It still possible, but I asked myself - why I have to do such ugly things in my favorite language? (When in Rails or Golang it would be a one-liner).
I realized that many times I needed a dynamic default, but each time instead of using this simple concept I was forced to do a workaround. Sometimes spending significant time on a thing that should be simple. But it was… acceptable. Then I found this case where I wasn’t able to fix it even after couple of hours. And I realized that it’s probably easier to create a library that adds dynamic defaults to Elixir. And here we’re. =)
Hope that example above works)
0
stefanluptak
Just thinking out lout here and the whole thing is a matter of year or even two. But could this maybe be solved (at least partially) by the future typed structs? If you would declare your field as being DateTime (for example). You would then be forced everywhere you’re trying to create this struct to provide that value? The ergonomics wouldn’t be ideal, but at least there won’t be any missed case.
0
sodapopcan
Sorry I don’t want to pile too much onto the detractor side but I think this in a nutshell is the problem. Again I would have to see code but I don’t know why something like would be ugly or why it would have to change in so many places no matter how big the project. Unless you are doing something like Repo.get(Struct, 1) everywhere (web layer, api layer) instead of going through a domain function 
0
ffloyd
Hmm. Interesting! It will work for many cases but I’m afraid not for Ecto virtual fields: Ecto creates struct instances inside their helper (MyStruct.__schema__(:loaded)). The helper is generated by schema do ... end macro. It will try to create a record with defaults from field/3 definitions and I haven’t found any documented way to override it.
Might be I need to be more explicit of my goal here: It’s not about finding a way how to reliably refactor in order to introduce a dynamic default.
I want to find a way to avoid refactoring when I introduce a dynamic default to an existing struct in a big (500k+ lines) project. And find a way to define static and dynamic defaults using similar syntax, both in Elixir stdlib and libraries.
0