From: Thomas 'PointedEars' Lahn on
Matt Kruse wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Matt Kruse wrote:
>> > Thomas 'PointedEars' Lahn wrote:
>> >> > I'm not building this for idiots!
>> >> ISTM you are not building this for people who do DOM scripting either.
>> >> <form>...<input name="foo[]">...</form>
>> > This already works fine:
>> > $prop(document, "forms[0].foo[].value")
>> > for example.
>> You miss the point.
>
> On the contrary, you fail to make one.

It is not that hard to miss, see <news:2882225.eEdlvqk35O(a)PointedEars.de>.


PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
From: Thomas 'PointedEars' Lahn on
Matt Kruse wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Your shortsightedness blinds you again for the possibilities that await
>> you. As long as you choose string delimiters for separating parts of the
>> /MemberExpression/ used to access a property, your implementation will
>> not be able to deal with objects that have properties with names that
>> contain those delimiters.
>
> [...]
> Matt "the key to picking a good delimiter is to use one that is not
> contained in your string expression" Kruse

How naive are you anyway? *Any* Unicode character may be contained in a
property name. The only way for you to work around that problem is to
provide a way for the user of the function/library to define the
delimiter(s) before or upon the call and to make the provision that property
names of the object do not contain it/them.

However, no such provision is necessary and it it is more efficient, a lot
more simple and compatible not to use a string delimiter that you need to
split on in the first place.


PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
From: Scott Sauyet on
Thomas 'PointedEars' Lahn wrote:
> Matt Kruse wrote:
>> Thomas 'PointedEars' Lahn wrote:
>>> No, by contrast you will not be able to handle property names that
>>> contain `|'.
>
>> Umm, then you just pick a different delimiter that doesn't conflict
>> with your property names. Duh.
>
> Your shortsightedness blinds you again for the possibilities that await you.  
> As long as you choose string delimiters for separating parts of the
> /MemberExpression/ used to access a property, your implementation will not
> be able to deal with objects that have properties with names that contain
> those delimiters.

While I agree with what seems to be the majority opinion that strings
with delimiters are not the best solution, I'm not sure I can buy this
objection. Matt said he was passing alternative delimiters as an
additional parameter to the call. Since the presumed use is something
like

var xyz = $prop(document, "forms[0].foo[].value");

or if necessary,

var xyz = $prop(obj, 'property|.property.|[property]', '|');

and not

var xyz = $prop(obj, myStringVar);

it's easy enough to see by inspection that the delimiter is not
included in the string. The point is that this is to be used for
known source code and data structures; it's simply a mechanism to
avoid the nested chains of checking on the existence of intermediate
properties on the chain. It's not, in my understanding, an attempt to
provide a general-purpose property-fetching API for arbitrary data
structures.

If you've used a Java template engine such as Velocity or Freemarker,
it would be an attempt at something similar to the dotted property
access notation that they provide. Instead of code like:

public String fetch(MyClass myObj) {
if (myObj != null) {
SomeClass path = myObj.getPath();
if (myPath != null) {
AnotherClass to = myPath.getTo();
if (to != null) {
String property = to.getProperty();
if (property != null) {
return property;
}
}
}
}
return "";
}


these tools allow access the property like this:

${myObj.path.to.property}


The big difference in ECMASCript is that the period is allowed as part
of property identifiers. If Matt's code allowed you to, if necessary,
use this instead:

$prop(myObj "path~to~property", "~")

I simply don't see the issue.

-- Scott
From: Thomas 'PointedEars' Lahn on
Scott Sauyet wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Matt Kruse wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> No, by contrast you will not be able to handle property names that
>>>> contain `|'.
>>
>>> Umm, then you just pick a different delimiter that doesn't conflict
>>> with your property names. Duh.
>>
>> Your shortsightedness blinds you again for the possibilities that await
>> you. As long as you choose string delimiters for separating parts of the
>> /MemberExpression/ used to access a property, your implementation will
>> not be able to deal with objects that have properties with names that
>> contain those delimiters.
>
> While I agree with what seems to be the majority opinion that strings
> with delimiters are not the best solution, I'm not sure I can buy this
> objection. Matt said he was passing alternative delimiters as an
> additional parameter to the call. Since the presumed use is something
> like
>
> var xyz = $prop(document, "forms[0].foo[].value");
>
> or if necessary,
>
> var xyz = $prop(obj, 'property|.property.|[property]', '|');
>
> and not
>
> var xyz = $prop(obj, myStringVar);
>
> it's easy enough to see by inspection that the delimiter is not
> included in the string.

Utter nonsense.

First of all, to $prop() there is exactly no difference with regard to how
the value was passed. That's not only JavaScript 101, it's Programming 101.

Second, without further information the first property access could be the
equivalent of any of the following, with the list not making a claim to be
complete:

document.forms[0].foo.["[]"].value
document.forms[0]["foo[]"].value
document.forms["[0].foo[]"].value
document["forms[0]"]["foo[]"].value
document["forms[0].foo[]"].value
document["forms[0]"]["foo[].value"]
document["forms[0].foo[].value"]

With the second approach, it needs to be clearly defined which delimiter is
used if no delimiter is specified.

Third, with either solution the issue remains that a property name may not
contain the delimiter then, when that would not be necessary had a different
approach been chosen. IOW, it is not possible to access

obj["property"][".property."]["[prop|erty]"]

with

$prop(obj, 'property|.property.|[prop|erty]', '|')

because that would access

obj["property"][".property."]["[prop"]["erty]"]

instead. And if you defined `[' and `]' (or something else) as delimiter
for property names you would could not have property names that contained
them. Or your would have to implement an escape syntax so that those
characters are not considered delimiters, which would exclude those escape
sequences from being part of property names.

But all of this is completely unnecessary if you let the programming
language provide the delimiter, i.e. arguments, Arrays, or a combination
thereof.


PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
From: Thomas 'PointedEars' Lahn on
Thomas 'PointedEars' Lahn wrote:

> Scott Sauyet wrote:
>> var xyz = $prop(document, "forms[0].foo[].value");
>> [...]
>
> [...] without further information the first property access could be the
> equivalent of any of the following, with the list not making a claim to be
> complete:
>
> document.forms[0].foo.["[]"].value

document.forms[0].foo["[]"].value

> document.forms[0]["foo[]"].value
> document.forms["[0].foo[]"].value
> document["forms[0]"]["foo[]"].value
> document["forms[0].foo[]"].value
> document["forms[0]"]["foo[].value"]
> document["forms[0].foo[].value"]
> [...]


PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16