Yes, that's the approach I took, in fact. The issue with this approach are:
1. have to use a library to do what, I think, should be provided by the
core language (that's my personal opinion)
2. it still does not enforce in any way invariants. I can still do
invalid_struct = %MyStruct{} or %MyStruct{name: 5} even if the field in the
embedded schema is defined as :string
Using Ecto and changesets to validate the state of the struct does the job
in a way, but it does not ensure the struct is valid "at any time", which
is what I'd like to achieve instead.
On Thursday, 30 May 2019 18:29:19 UTC+1, Allen Madsen wrote:
>
> You're probably better off using an ecto schema and changeset.
>
> Allen Madsen
> http://www.allenmadsen.com
>
>
> On Thu, May 30, 2019 at 10:27 AM Francesco Lo Franco <
> [email protected] <javascript:>> wrote:
>
>> Sorry to dig up this very old post, but I thought I wanted to just +1
>> this proposed feature because I reckon it will be extremely useful for a
>> language such Elixir, which, besides, sees DDD being applied much more than
>> in the past. Is there any update or news about this? I'd be happy to know
>> more or contribute to this if helpful.
>>
>> On Monday, 6 November 2017 16:50:18 UTC, Rafał Radziszewski wrote:
>>>
>>> Hi,
>>> since I see a lot of potential in the feature I'd like to provide a
>>> couple of arguments in favour of it. I will use points for ease of
>>> discussion.
>>>
>>> 1. I am not going to talk about specific implementation (through @guard
>>> property) as proposed, but generally about giving possibility to create
>>> invariants in structs, i.e. possibility to raise on instantiating struct
>>> with invalid data.
>>> 2. No solution will be perfect (i.e. mentioned possibility of using
>>> Map.put/3 or manually creating struct as map through %{__struct__:
>>> MyStruct}, using those features is somehow similar to addressing raw memory
>>> in C - if you're doing it, you should expect problems), a lot can be
>>> achieved by modifying just struct/2, %MyStruct{} and %MyStruct{my_struct |
>>> key: val}, as those are prevalent in the codebase.
>>> 3. Though there is possibility to define function performing those
>>> validations (i.e. it is quite common to see new/1 in a lot of libraries),
>>> there is no way to restrict creation of struct to that functions. I believe
>>> it to be a good decision, since data is just data, but it makes it quite
>>> easy to make a mistake that is hard to pin down, since no warnings or any
>>> other suggestions are issued.
>>> 4. While it is correct that in general forcing users to use API is the
>>> way to go, literal struct creation is very common and in most cases
>>> correct, which can lead to confusion. It can also encourage extensive
>>> boilerplating of functions like 'new', just in case, which can be
>>> detrimental to language clarity.
>>> 5. Adding invariants does not breaks the premise of validating data on
>>> boundries, it supports it. Ability to restrict field values leads to
>>> cleaner code, since it is not necessary to check input validity in every
>>> function. Raising error on invalid instantiation actually forces to perform
>>> validation on the boundry - in the place where struct is instantiated. It
>>> allows for less defensive coding, since programmer can actually assume that
>>> struct is correct.
>>> 6. Matching on %Foo{} in this scenario doesn't actually cause problems,
>>> since the structure won't be even instantiated if it is wrong, unless it's
>>> manually put together from map.
>>>
>>> In general I believe that adding more possibilities to express ideas
>>> through types could really help the language.
>>>
>>> Cheers,
>>> Rafal
>>>
>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "elixir-lang-core" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected] <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/elixir-lang-core/895a5599-2f91-4abf-aeef-81adcfdffc2d%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/elixir-lang-core/895a5599-2f91-4abf-aeef-81adcfdffc2d%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
--
You received this message because you are subscribed to the Google Groups
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/elixir-lang-core/db5da3be-0e85-4bb8-9291-926c505fdd81%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
