The point wasn't about not typing long names :) Or about remapping. It was
about knowing when I have to know that the keys and corresponding variable
names were different, and when I don't.
Ultimately I think this either lives in core or nowhere else, and that if
people on a given project didn't like it they could lint it out w/ credo. I
don't feel like "everyone liking a given syntax" is a realistic goal.
One thing I've seen in common in both the previous thread, the forum post, and
here is that there is more agreement/interest in only supporting this syntax
for structs. I think that may be a good middle ground/compromise for us to
consider. It doesn't preclude us supporting *more* in the future also.
On Mon, Jun 26, 2023 at 5:52 PM, Justin Wood < m...@ankhers.dev > wrote:
>
> For what's it's worth, I generally see people wanting this for map
> deconstruction instead of construction. When it comes to deconstruction,
> we already have a different syntax for maps with atom keys.
>
>
>
> foo = %{bar: "baz"}
>
> foo. bar ( http://foo.bar/ )
>
>
>
>> Here is a really contrived example:
>>
>>
>>
>> `%Struct{some_xy1_stup4d_8345324_name: some_xy1_stup4d_8354324_name} =
>> value
>>
>>
>
>
>
> To me, this contrived example lends itself to not supporting this syntax.
> Personally, if I recieved some JSON or something else that had such a long
> and complicated name, I would opt to somehow shorten the variable name in
> my code. So I would choose to not use this syntax as I would not want to
> have to type that huge variable name multiple times, even with the help of
> auto complete.
>
>
>
> Another point to think about is that the internals of our programs do not
> always translate 1:1 through every boundary in our program. UI elements
> get renamed, features get renamed, etc. It is much easier to just rename a
> map key at one of my application boundaries instead of having to rename
> every use of a given variable in order to support this feature.
>
>
>
> Just a few quick thoughts.
>
>
>
> Justin
>
>
>
>
> --
> 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 elixir-lang-core+unsubscribe@ googlegroups. com (
> elixir-lang-core+unsubscr...@googlegroups.com ).
> To view this discussion on the web visit https:/ / groups. google. com/ d/
> msgid/ elixir-lang-core/ 91427e5d-951f-4bbc-b63e-ffa1eabf3c56%40app. fastmail.
> com (
> https://groups.google.com/d/msgid/elixir-lang-core/91427e5d-951f-4bbc-b63e-ffa1eabf3c56%40app.fastmail.com?utm_medium=email&utm_source=footer
> ).
>
--
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 elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elixir-lang-core/ljdebml4.7ef759cb-f841-4643-aaab-1eb4d0e23fb7%40we.are.superhuman.com.
