Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #30598

Re: not "autovivification", but ...?

Show key headers only | View raw

Michael Haufe (TNO) wrote:
> On Wednesday, June 1, 2016 at 12:50:01 PM UTC-5, Stefan Weiss wrote:
> 
>> I sort of agree with this, to a point, but only if I created the data
>> structure myself (or my application did). In many situations we simply don't
>> have that level of control over data. Examples for this would be external
>> APIs, JSON config files, or any other external tree-like structure mapped to
>> nested objects.
> 
>> Are you saying that all data exchange formats with optional components are
>> badly designed, 
> 
> No. Nothing like that at all. 
> 
>> or that at least all known container nodes should be
>> present? I don't think that's a realistic requirement.
> 
> Nor this either.
> 
> Let me try to approach this another way to try and clarify my meaning:

[summarized ways to access nested properties, if I understood correctly:]

a) rely on the structure: someObject.left.right.right.left.value
b) use a custom walk() method (or similar)
c) use a specialized operator (like `?.`)
d) spread across multiple functions
e) use an alternate identifier (id attributes in the DOM)
f) use something like JSONPath
g) use a decorator to provide the search/path feature

While this is a very useful list of techniques, I'm even more confused
now... These are all used when we don't know if a certain branch (or path
component) exists in a nested object. I thought your earlier point was that
this situation shouldn't be allowed to occur in a well-designed application,
but I'm probably misunderstanding something here:

Michael Haufe (TNO) wrote:
>>> The dual issue for implicit creation is accessing a nested structure
>>> where one or more of the intermediate members may not exist. My same
>>> question above applies there as well: Why don't these already exist?
>>>
>>> I think the lack of desire to revisit the architecture of the
>>> application leads to some interesting choices in how people code [...]


I'm not trying to make a case for implicitly *creating* multiple levels in a
nested structure - even where that is supported, I usually go out of my way
to avoid it. See the Perl example in my first reply. But accessing such a
structure is very common and often cannot be avoided. Which of the mentioned
techniques is used to solve this is a matter of preference, IMO.


- stefan


PS, a little off-topic: PHP is probably the worst language to work with in
this regard. It will happily allow implicit multi-level creation in arrays -

   // ($foo is unused up to this point)
   $foo["bar"][13]["baz"] = "qux";

- but will emit E_NOTICE (a type of error) if we try to read a nonexistent
index ($foo["x"]). Only with the relatively recent release of PHP7 did it
get a null-coalescing operator:

   $x = $foo["baz"][14]["bar"] ?? "qux";

And when objects are involved... best not to think about it.

Back to comp.lang.javascript | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: not "autovivification", but ...? Stefan Weiss <krewecherl@gmail.com> - 2016-05-31 14:38 +0200
  Re: not "autovivification", but ...? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-06-01 08:03 -0700
    Re: not "autovivification", but ...? Stefan Weiss <krewecherl@gmail.com> - 2016-06-01 19:49 +0200
      Re: not "autovivification", but ...? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-06-01 14:29 -0700
        Re: not "autovivification", but ...? Stefan Weiss <krewecherl@gmail.com> - 2016-06-02 01:29 +0200
          Re: not "autovivification", but ...? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-06-02 02:16 +0200
            Re: not "autovivification", but ...? Stefan Weiss <krewecherl@gmail.com> - 2016-06-02 13:20 +0200
          Re: not "autovivification", but ...? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-06-02 15:51 -0700

csiph-web