When we're dealing with code this small, I don't think readability is as
important of an element. Personally I would do `((a) => a.name)`, which is
short and, most importantly, very explicit about what it is doing. If you
know what a function is and you know what a property is, you know what this
code does. Adding additional syntax to a language requires increasingly
esoteric knowledge of said language.
On Sat, Jun 22, 2019 at 7:13 PM Bob Myers <r...@gol.com> wrote:
> The world is awash in subjectivity.
>
> We can nevertheless hope to find broad agreement on at least a transitive
> ranking of attributes such as readability; if we don't think we can, then
> we are epistemological nihilists with no criteria whatsoever on which to
> base our language design decisions and this mailing list would have no
> raison d'etre, since we would never be able to align on anything.
>
> However subjective the notion of readability, I think few would disagree
> that the first fragment below is more readable than the second.
>
> ```
> .name
> ```
>
> and
>
> ```
> ({name}) => name
> ```
>
> The first is also more reliable by most measures, because it removes the
> possibility of misspelling one of the instances of ```name``` in the
> second, which we would prefer not to rely entirely opn type checkers or
> linters to pick up.
>
> Yes, to read the first does require additional knowledge, namely of the
> fact that the syntax ```<dot>property``` denotes a function to retrieve the
> value of the property by that name. But this is no more a readability
> problem than the fact that one must have knowledge of the English worrds in
> a sentence in order for them to be "readable". Such knowledge is often
> referred to by terms such as "cognitive footprint". Yes, this proposal does
> have a cognitive footprint. But all language features have cognitive
> footprints, requiring that people writing and reading code using the
> feature have knowledge of the feature. The issue then becomes the *size* of
> the cognitive footprint in relation to the benefit--an equation both sides
> of which involve subjectivity...
>
> Of course, I did not mean to imply that readability or reliability in and
> ot themselves are either necessary or sufficient for a new languge feature,
> There are many other aspects, as many as a dozen, which have been discussed
> and defined in earlier threads.
>
> Bob
>
> On Sat, Jun 22, 2019 at 12:08 PM guest271314 <guest271...@gmail.com>
> wrote:
>
>> > If the requirement is merely to write a function to pick properties,
>> yes. If the requirement is to do that in a more concise, readable, reliable
>> way, no.
>>
>> The term "readable" is entirely subjective. As far as am aware there is
>> no standard for "readable" (in any language, coding or not). Even if such
>> criteria for "readable" did exist in some institutional document, no author
>> of code (or anything else) is bound to recognize or adhere to any such
>> subjective and arbitrary criteria.
>>
>> What specific definition of "reliable" is being used, and what are the
>> cases that demonstrates using destructing assignment is not "reliable"?
>>
>> On Sat, Jun 22, 2019 at 6:50 PM Bob Myers <r...@gol.com> wrote:
>>
>>> On Sat, Jun 22, 2019 at 10:59 AM guest271314 <guest271...@gmail.com>
>>> wrote:
>>>
>>>> Does not destructuring assignment provide a means to achieve the
>>>> requirement?
>>>>
>>>
>>> If the requirement is merely to write a function to pick properties,
>>> yes. If the requirement is to do that in a more concise, readable, reliable
>>> way, no.
>>>
>> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
