W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: [DOM4] Remove Node.isSameNode

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 15 Sep 2011 00:13:55 -0700
Message-ID: <CA+c2ei-GQmeDhcR7CwyLago7O+UXsdB=72eFUQ-7g=y=U47QNQ@mail.gmail.com>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
Cc: Webapps WG <public-webapps@w3.org>
On Fri, Sep 9, 2011 at 7:24 PM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
> * Jonas Sicking wrote:
>>It's a completely useless function. It just implements the equality
>>operator. I believe most languages have a equality operator already.
> It's quite normal for object models to not guarantee that "the" equality
> operator works for object identity comparison, COM being a prime example
> where this is only guaranteed for IUnknown pointers. Leading to issues
> like http://www.mail-archive.com/mozilla-xpcom@mozilla.org/msg05045.html
> but that's life.

This just means that for COM objects, the equality operator is not the
C++ equality operator. You'll note that COM generally doesn't
introduce a isSameX function for each and every interface, but instead
relies on people QIing to IUnknown.

> It is also useful to have this as function available in
> environments where "the object identity operator" is not available as a
> function. In JavaScript, if function arity is ignored as is typical,
>  [].some.call(nodelist, node.isSameNode, node)
> can be used to check whether a node is in a node list, the "equivalent"
>  [].some.call(nodelist, function(elem) { return elem === node; })
> is a good bit worse if you want to use this as condition in an if block
> as you would run past line length restrictions easily and would have to
> put this on several lines.

This logic would also dictate that we should introduce isNotSameNode,
isParentNode, isNextSiblingNode, isPreviousSiblingNode, etc functions.
And of course, isSameBlob, isSameXMLHttpRequest, isSameCSSRule etc.

I would prefer to have people write the little bit of extra code
needed in your second example above.

> Using proxying wrappers is quite a common
> practise http://code.activestate.com/lists/python-list/399236/ so I do
> not see why everybody should spend resources removing this method.

I can guarantee that the people that will have to spend resources
removing this function would spend more resources if it's kept. Just
in the last two weeks I've spent more resources ensuring that this
function works than it would take for me to remove it from Firefox.

/ Jonas
Received on Thursday, 15 September 2011 07:14:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:23 UTC