[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.javascript

Recursive function to find a node in the DOM

danca

7/15/2015 7:59:00 AM

I wrote this small recursive function to find a node (having a name) in
a DOM element:

//usage: nodeFind (element to inspect (object), f.e. a form, name of the
element to search for, 3rd parameter empty at first call)

function nodeFind(el,n,retval){
if (el.name==n) {
return (el)
}else{
if (el.hasChildNodes) {
for (var z=0;z<el.childNodes.length;++z){
var a=el.childNodes.item(z);
retval=nodeFind(a,n,retval)
}
}
}
return retval
//^^^^^^^^^^^^ note!
}

I needed to find a specific control in a form, in order to substitute an
<input readonly> with a <file> (via replaceChild()) to upload a file if
the form is prevalidated, etc.
(then IIRC I discovered that IE was not able to refer to the substitued
control via <form>[name] - this is another story :-) )

I put it in public domain if ever some newbies finds it useful, and
obviously to discuss with "big chops" here if this is robust enough to
be considered cross-browser and definitive.

I am using it from long time and it seems to work well on every browser.
One strange thing is the way recursion is implemented in javascript: I
did not put the "return retval" statement at first, it seems unuseful,
and went crazy before discovering that it is needed.

Dan
--
"Everybody should pay taxes with a smile"
I tried, but they want money.
31 Answers

Thomas 'PointedEars' Lahn

7/15/2015 9:57:00 AM

0

danca (Daniele Campagna) wrote:

> I wrote this small recursive function to find a node (having a name) in
> a DOM element:
>
> //usage: nodeFind (element to inspect (object), f.e. a form, name of the
> element to search for, 3rd parameter empty at first call)
>
> function nodeFind(el,n,retval){
> if (el.name==n) {
> return (el)
> }else{
> if (el.hasChildNodes) {
> for (var z=0;z<el.childNodes.length;++z){
> var a=el.childNodes.item(z);
> retval=nodeFind(a,n,retval)
> }
> }
> }
> return retval
> //^^^^^^^^^^^^ note!
> }

document.forms[â?¦].elements[â?¦] and getElementsByTagName(â?¦) exist. You do not
need that function even for Netscape Navigator 2 (the fact aside that it
would not work there as it is).

> I needed to find a specific control in a form, in order to substitute an
> <input readonly> with a <file> (via replaceChild()) to upload a file if
> the form is prevalidated, etc.
> (then IIRC I discovered that IE was not able to refer to the substitued
> control via <form>[name] - this is another story :-) )

If you can change the input[type="text"] into an input[type="file"], for
security reasons the value of the control will be reset, so this appears to
be a futile exercise (other than to test the security fix).

> I am using it from long time and it seems to work well on every browser.

â?¦ that you know about and have tested.

> One strange thing is the way recursion is implemented in javascript: I
> did not put the "return retval" statement at first, it seems unuseful,
> and went crazy before discovering that it is needed.

There is no â??javascriptâ?. Of course you need a break condition to prevent
infinite recursion; this has nothing to do with what you think would be
â??javascriptâ?. And the proper approach here is iteration (walking the
document tree), not recursion; because the stack size and/or nesting level
is limited (the Google Groups archive has test results), but an elementâ??s
nesting level within a document tree is not.

--
PointedEars
FAQ: <http://PointedEars.... | SVN: <http://PointedEars.de...
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-...
Please do not cc me. / Bitte keine Kopien per E-Mail.

Thomas 'PointedEars' Lahn

7/15/2015 10:00:00 AM

0

danca (Daniele Campagna) wrote:

> I wrote this small recursive function to find a node (having a name) in
> a DOM element:
>
> //usage: nodeFind (element to inspect (object), f.e. a form, name of the
> element to search for, 3rd parameter empty at first call)
>
> function nodeFind(el,n,retval){
> if (el.name==n) {
> return (el)
> }else{
> if (el.hasChildNodes) {
> for (var z=0;z<el.childNodes.length;++z){
> var a=el.childNodes.item(z);
> retval=nodeFind(a,n,retval)
> }
> }
> }
> return retval
> //^^^^^^^^^^^^ note!
> }

document.forms[â?¦].elements[â?¦] and getElementsByTagName(â?¦) exist. You do not
need that function even for Netscape Navigator 2 (the fact aside that it
would not work there as it is).

> I needed to find a specific control in a form, in order to substitute an
> <input readonly> with a <file> (via replaceChild()) to upload a file if
> the form is prevalidated, etc.
> (then IIRC I discovered that IE was not able to refer to the substitued
> control via <form>[name] - this is another story :-) )

If you can change the input[type="text"] into an input[type="file"], for
security reasons the value of the control will be reset, and you cannot set
the â??valueâ? property of an input[type="file"] for the same reason. So this
appears to be a futile exercise (other than to test the security fix).

> I am using it from long time and it seems to work well on every browser.

â?¦ that you know about and have tested.

> One strange thing is the way recursion is implemented in javascript: I
> did not put the "return retval" statement at first, it seems unuseful,
> and went crazy before discovering that it is needed.

There is no â??javascriptâ?. Of course you need a break condition to prevent
infinite recursion; this has nothing to do with what you think would be
â??javascriptâ?. And the proper approach here is iteration (walking the
document tree), not recursion; because the stack size and/or nesting level
is limited (the Google Groups archive has test results), but an elementâ??s
nesting level within a document tree is not.

--
PointedEars
FAQ: <http://PointedEars.... | SVN: <http://PointedEars.de...
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-...
Please do not cc me. / Bitte keine Kopien per E-Mail.

Thomas 'PointedEars' Lahn

7/15/2015 10:04:00 AM

0

Thomas 'PointedEars' Lahn wrote:

> danca (Daniele Campagna) wrote:
>> I wrote this small recursive function to find a node (having a name) in
>> a DOM element:
>>
>> //usage: nodeFind (element to inspect (object), f.e. a form, name of the
>> element to search for, 3rd parameter empty at first call)
>>
>> function nodeFind(el,n,retval){
>> if (el.name==n) {
>> return (el)
>> }else{

Unnecessary â??elseâ? block. (You *really* want to start using a decent IDE
with semantic validation.)

>> [â?¦]
>> }
>
> document.forms[â?¦].elements[â?¦] and getElementsByTagName(â?¦) exist.

I mean getElementsByName(â?¦), of course.

> You do not need that function even for Netscape Navigator 2 (the fact
> aside that it would not work there as it is).

--
PointedEars
FAQ: <http://PointedEars.... | SVN: <http://PointedEars.de...
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-...
Please do not cc me. / Bitte keine Kopien per E-Mail.

danca

7/15/2015 11:36:00 AM

0

Il 07/15/2015 11:59 AM, Thomas 'PointedEars' Lahn ha scritto:
>
> document.forms[â?¦].elements[â?¦] and getElementsByTagName(â?¦) exist. You do not
> need that function even for Netscape Navigator 2 (the fact aside that it
> would not work there as it is).
>

The idea was to have a very generalized function. It finds whatever
<name> in whatever <container>, and is used in a series of web
applications I wrote, so I'm not tied to a tagName nor I use it only for
forms...

>
> If you can change the input[type="text"] into an input[type="file"], for
> security reasons the value of the control will be reset, and you cannot set
> the â??valueâ? property of an input[type="file"] for the same reason. So this
> appears to be a futile exercise (other than to test the security fix).

I know of that. But it is not an exercise. The scenario here is: a user
can post a message in a [kinda of] message system. Messages can have
attachments. If the author wants to edit the message he posted, he may
want to change the text or the attachment. So he has a button "change
attachment", and the input showing the name of the actual attachment
becomes a <file> to select another one and upload it. :-)

>
>> One strange thing is the way recursion is implemented in javascript: I
>> did not put the "return retval" statement at first, it seems unuseful,
>> and went crazy before discovering that it is needed.
>
> There is no â??javascriptâ?.

ECMA, ok, ECMA.

Of course you need a break condition to prevent
> infinite recursion; this has nothing to do with what you think would be
> â??javascriptâ?.

Well I only wanted to point out that in other languages (f.e. xbase, the
main language I use - to write CGI's at present -) I would have written
the very same function with no need to put a return statement there.

And the proper approach here is iteration (walking the
> document tree), not recursion; because the stack size and/or nesting level
> is limited (the Google Groups archive has test results), but an elementâ??s
> nesting level within a document tree is not.
>

Yes, but all this stuff is server-side generated, so I am quite in
control of the pages (they are small in size) and I must confess that I
like very much the recursive approach - but I am aware of the stack
growth and memory consumption it causes.

Dan
--
"Everybody should pay taxes with a smile"
I tried, but they want money.

Scott Sauyet

7/18/2015 11:00:00 PM

0

Thomas 'PointedEars' Lahn wrote:
> danca (Daniele Campagna) wrote:
>
>> I wrote this small recursive function to find a node (having a name) in
>> a DOM element:
>>
>> //usage: nodeFind (element to inspect (object), f.e. a form, name of the
>> element to search for, 3rd parameter empty at first call)
>>
>> function nodeFind(el,n,retval){
>> if (el.name==n) {
>> return (el)
>> } else {
>> if (el.hasChildNodes) {
>> for (var z=0;z<el.childNodes.length;++z){
>> var a=el.childNodes.item(z);
>> retval=nodeFind(a,n,retval)
>>
>> }
>> }
>> return retval
>> //^^^^^^^^^^^^ note!
>> }
> [ ... ]
>
>> One strange thing is the way recursion is implemented in javascript: I
>> did not put the "return retval" statement at first, it seems unuseful,
>> and went crazy before discovering that it is needed.

That is not really an issue with recursion. This has to do with the way
Javascript passes values to functions. It uses a specialization of call
by value, sometimes known as "call by sharing". The reference the caller
has stored as `retval` is not passed to the function. Instead a *copy*
of that reference is passed. Both refer initially to the same object.
But when, inside the function, you reassign the new reference, the caller's reference is left alone. This shouldn't be too surprising if you've dealt
with languages like Java, Ruby, Python, or even Scheme; they all use a
similar technique.


> There is no "javascript". [ ... ]

Keep tilting at that windmill. The rest of us know better.


> And the proper approach here is iteration (walking the
> document tree), not recursion; because the stack size and/or nesting level
> is limited (the Google Groups archive has test results), but an element's
> nesting level within a document tree is not.

Recursion is logically correct here. If you're working with modern browsers,
you'll have at least a 20000-call deep recursion stack.. If you have a tree
that deep in your document, heaven help you. If you have to support IE6 - IE8,
you'll still get well over 1000 calls deep. I don't know about you, but I've
never written a document with that much nesting.

A recursive solution is clear and elegant. A non-recursive version would be
much less so. If you make it tail-recursive, when browsers start to optimize
tail-recursion, the little performance penalty you would currently pay for
recursion will be eliminated.

-- Scott

Thomas 'PointedEars' Lahn

7/19/2015 10:27:00 AM

0

danca (Daniele Campagna) wrote:

> Il 07/15/2015 11:59 AM, Thomas 'PointedEars' Lahn ha scritto:
>> document.forms[â?¦].elements[â?¦] and getElementsByTagName(â?¦) exist. You do
>> not need that function even for Netscape Navigator 2 (the fact aside that
>> it would not work there as it is).
>
> The idea was to have a very generalized function. It finds whatever
> <name> in whatever <container>, and is used in a series of web
> applications I wrote, so I'm not tied to a tagName nor I use it only for
> forms...

See my correction. You can use the getElementsByName(â?¦) method for that; it
is available on HTML document objects in implementations of W3C DOM Level 2
HTML (since 2003) and HTML5.

The getElementsByName(â?¦) method is not available on element objects (at
least not in a standards-compliant way; implementations may vary); however,
the getElementsByTagName(â?¦) method is, starting from IE/MSHTML 5.5 at the
latest. That method can be called as element.getElementsByTagName("*"), and
the resulting NodeList can be filtered, if you do not want to be tied to a
specific â??tagNameâ? property value. If all else fails, the return value of
document.getElementsByTagName("*") can be filtered.

Higher Levels of the W3C DOM, implemented in recent Web layout engines,
support other such methods that are more flexible, too:
document.evaluate(â?¦) for XPath queries, and document.querySelector(â?¦) and
document.querySelectorAll() for CSS queries.


Also, you are reinventing the wheel. Several common libraries provide such
a function, by using a query engine or otherwise. So I do not foresee many
people being interested in your function.

That said, I do not see why you would need this algorithm that finds an
element by name in any context in the first place because there are more
efficient built-in ones. The â??nameâ? attribute is only allowed for the
following element types (cf. [1] and [2]):

- â??aâ? elements:

It is more efficient to filter â??document.linksâ? or the return value of
node.getElementsByTagName("a"). Where â??document.linksâ? is not only a
NodeList but a HTMLCollection, document.links["â?¦"] is the most efficient
approach.

Also, the â??nameâ? attribute is obsolete for â??aâ? elements since HTML5, in
favor of the â??idâ? attribute which allows those â??aâ? elements to be
referred by the return value of document.getElementById(â?¦).

- â??appletâ? elements:

It is more efficient to filter document.applets or the return value of
node.getElementsByTagName("applet"). Also, the â??appletâ? element is
deprecated in HTML 4, and obsolete since HTML5.

- â??formâ? elements:

It is more efficient to use document.forms["â?¦"].

- form controls:

There should not be form controls in an HTML document that are not part
of a form. Only an ancestor â??formâ? element guarantees proper validation
in HTML 5, and that this event works without client-side scripting
everywhere. Controls of a specific form can be referred to by name
with document.forms[â?¦].elements["â?¦"].

In most cases it is not even necessary to refer to the form by name
or index because form controls have a â??formâ? property to refer to the
form they are a part of, and â??thisâ? can be used in event-handler
attributes and event listeners to refer to the element object for the
element that fired the event.

However, in case a form control is not part of a form,
document.getElementsByName("â?¦"), document.getElementById("â?¦"), or
node.getElementsByTagName("â?¦") suffice. Because the same name SHOULD
NOT be used for different kinds of element types, such as both for an
â??objectâ? element and a form control.

- â??frameâ? and â??iframeâ? elements:

It is more efficient to use window.frames["â?¦"].

- â??imgâ? elements

It is more efficient to use document.images["â?¦"]. Also, the â??nameâ?
attribute is obsolete for â??imgâ? elements since HTML5.

- â??mapâ? elements:

It is more efficient to filter the return value of
node.getElementsByTagName("map").

- â??metaâ? elements:

It is more efficient to filter the return value of
node.getElementsByTagName("meta") or, because the â??nameâ? attribute
of META elements has historically been of the NAME type, there would
not be more than one element with that name in the document, and
document.getElementsByName("â?¦") can be used.

- â??objectâ? elements:

It is more efficient to filter document.applets or the return value of
node.getElementsByTagName("object").

<http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-85...

- â??paramâ? elements:

It is more efficient to filter the return value of
node.getElementsByTagName("param").

[1] <http://www.w3.org/TR/1999/REC-html401-19991224/index/attribute...
[2] <http://www.w3.org/TR/2014/REC-html5-20141028//index.html#attrib...

>> If you can change the input[type="text"] into an input[type="file"], for
>> security reasons the value of the control will be reset, and you cannot
>> set the â??valueâ? property of an input[type="file"] for the same reason.
>> So this appears to be a futile exercise (other than to test the security
>> fix).
>
> I know of that. But it is not an exercise. The scenario here is: a user
> can post a message in a [kinda of] message system. Messages can have
> attachments. If the author wants to edit the message he posted, he may
> want to change the text or the attachment. So he has a button "change
> attachment", and the input showing the name of the actual attachment
> becomes a <file> to select another one and upload it. :-)

(â??Exerciseâ? was not to be understood verbatim.) See my correction. There
appears to be no point to use a read-only input[type="text"] element here if
you want to support IE/MSHTML because you need to replace the element in any
case.

>>> One strange thing is the way recursion is implemented in javascript: I
>>> did not put the "return retval" statement at first, it seems unuseful,
>>> and went crazy before discovering that it is needed.
>>
>> There is no â??javascriptâ?.
>
> ECMA, ok, ECMA.

There is no ECMA (anymore). There are Ecma International, and the
ECMAScript Language Specification (named for historical reasons). But what
matters more than the name is the fact that this specification has several
*different* implementations; several of them have â??JavaScriptâ? in their
name.

> Of course you need a break condition to prevent infinite recursion; this
> has nothing to do with what you think would be â??javascriptâ?.
>
> Well I only wanted to point out that in other languages (f.e. xbase, the
> main language I use - to write CGI's at present -) I would have written
> the very same function with no need to put a return statement there.

I do not know xbase. ECMAScript is a language of the C family, so you need
to return a value from a function if you want to avoid an implicit return
value. The implicit return value is the â??undefinedâ? value in ECMAScript
implementations.

> And the proper approach here is iteration (walking the
>> document tree), not recursion; because the stack size and/or nesting
>> level is limited (the Google Groups archive has test results), but an
>> elementâ??s nesting level within a document tree is not.
>
> Yes, but all this stuff is server-side generated, so I am quite in
> control of the pages (they are small in size) and I must confess that I
> like very much the recursive approach - but I am aware of the stack
> growth and memory consumption it causes.

Above you have claimed generality for this function, and you have expressed
desire to make it available to the public because of that. It fails to do
that job if it does not work with any document.

--
PointedEars
FAQ: <http://PointedEars.... | SVN: <http://PointedEars.de...
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-...
Please do not cc me. / Bitte keine Kopien per E-Mail.

Thomas 'PointedEars' Lahn

7/19/2015 10:34:00 AM

0

Thomas 'PointedEars' Lahn wrote:

> [â?¦] You can use the getElementsByName(â?¦) method for that;
> it is available on HTML document objects in implementations of W3C DOM
> Level 2 HTML (since 2003) and HTML5.
>
> The getElementsByName(â?¦) method is not available on element objects (at
> least not in a standards-compliant way; implementations may vary);
> however, the getElementsByTagName(â?¦) method is, starting from IE/MSHTML
> 5.5 at the latest. That method can be called as
> element.getElementsByTagName("*"), and the resulting NodeList can be
> filtered, if you do not want to be tied to a specific â??tagNameâ? property
> value. If all else fails, the return value of
> document.getElementsByTagName("*") can be filtered.

[References that were accidentally cut from the draft: ]

<https://html.spec.whatwg.org/multipage/dom.html#dom-tree-accessors:dom-document-getelements...

<http://www.w3.org/TR/dom/#dom-element-getelementsbyt...

> Higher Levels of the W3C DOM, implemented in recent Web layout engines,
> support other such methods that are more flexible, too:
> document.evaluate(â?¦) for XPath queries, and document.querySelector(â?¦) and
> document.querySelectorAll() for CSS queries.

<http://www.w3.org/TR/DOM-Level-3-XPath/xpath.html#XPathEvaluator-ev...

<http://www.w3.org/TR/2013/REC-selectors-api-20130221/#interface-defin...

--
PointedEars
FAQ: <http://PointedEars.... | SVN: <http://PointedEars.de...
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-...
Please do not cc me. / Bitte keine Kopien per E-Mail.

danca

7/21/2015 10:08:00 AM

0

Il 07/19/2015 12:27 PM, Thomas 'PointedEars' Lahn ha scritto:

>
> See my correction. You can use the getElementsByName(â?¦) method for that; it
> is available on HTML document objects in implementations of W3C DOM Level 2
> HTML (since 2003) and HTML5.
>
> The getElementsByName(â?¦) method is not available on element objects (at
> least not in a standards-compliant way; implementations may vary); however,
> the getElementsByTagName(â?¦) method is, starting from IE/MSHTML 5.5 at the
> latest. That method can be called as element.getElementsByTagName("*"), and
> the resulting NodeList can be filtered, if you do not want to be tied to a
> specific â??tagNameâ? property value. If all else fails, the return value of
> document.getElementsByTagName("*") can be filtered.
>
> Higher Levels of the W3C DOM, implemented in recent Web layout engines,
> support other such methods that are more flexible, too:
> document.evaluate(â?¦) for XPath queries, and document.querySelector(â?¦) and
> document.querySelectorAll() for CSS queries.
>
>
> Also, you are reinventing the wheel. Several common libraries provide such
> a function, by using a query engine or otherwise. So I do not foresee many
> people being interested in your function.

OK, but I don't use any for now (apart the possibility I offer to have
the photo gallery managed via jQuery + fancybox - if one absolutely
wants that nice animation effect and is fine with the 100+ Kb of overhead).

>
> That said, I do not see why you would need this algorithm that finds an
> element by name in any context in the first place because there are more
> efficient built-in ones. The â??nameâ? attribute is only allowed for the
> following element types (cf. [1] and [2]):
>
> - â??aâ? elements:
....
Many thanks, this is a very useful summary (and I will add it to my
fragments of documentation i collect here and there). Very clear. But
IIUC, I would need different functions for different elements, and maybe
feature testing for getElementsByName...

>
> - form controls:
>
> There should not be form controls in an HTML document that are not part
> of a form. Only an ancestor â??formâ? element guarantees proper validation
> in HTML 5, and that this event works without client-side scripting
> everywhere. Controls of a specific form can be referred to by name
> with document.forms[â?¦].elements["â?¦"].

As I said previously, if you have:

<html>
....
<form name... method=POST action...>
<INPUT TYPE=TEXT NAME=aName VALUE="blah">
</form>
....
</html>

and then you replace the <INPUT> element :
<script>
....
// oldEl is the element, obtained via gEBI or whatever
newEl=document.createElement("input");
newEl.name="aName";
newEl.type="file";
oldEl.parentNode.replaceChild(newEl,oldEl);

console.log(document.forms[0].aName.);
....
</script>

IE 7 (and IE 8 in compatibility mode) both show a gracious bug. At the
time I made the test I wrote nodeFind(), that does not fail with any
known [by me] browser. IIRC there were cross-browsers problems with
getElementsByTagName at the time - not sure of that, anyway.

[apologize mode ON]
the fact is, I have to deal with my incomplete knowledge of different
implementations of ECMAscript, different Levels of W3C DOM, different
behaviour of different browsers and, in general, incomplete knowledge
/per se/ :-), and the difficulty to keep up with the browser's
evolution. Consequently, I try to avoid risks of cross-browsers
incompatibility (and right now a new class of problems seems to arise
with new devices such as smartphone, tablets and God knows what else:
adaptive web design for one...). I must choose: and "the better is enemy
of the good" (old italian proverb) has been proven to be a useful rule
of thumb for me. I sometimes feel like an illiterate trying to write a
poem, but I must do my best with the scarce resources I have (and this
is true for me as for everyone else - just "scarce" has a different
meaning).

JFC, here are some issues I remember I had to face in last years, apart
the previously described one:
- getElementsByName/getElementsByTagName not implemented
- mysterios bug in Opera in printing a frame
- bug in Opera in iframes readystate
- bug in IE about the test for the existence of a method in designmode
- bug in Firefox if trying to get a specific property of a window
- try... catch not implemented
- the old problem of knowing if a page is completely loaded and rendered

....and so on, I can't remember all of them. :-)

[apologize mode OFF]

>>
>> I know of that. But it is not an exercise. The scenario here is: a user
>> can post a message in a [kinda of] message system. Messages can have
>> attachments. If the author wants to edit the message he posted, he may
>> want to change the text or the attachment. So he has a button "change
>> attachment", and the input showing the name of the actual attachment
>> becomes a <file> to select another one and upload it. :-)
>
> (â??Exerciseâ? was not to be understood verbatim.) See my correction. There
> appears to be no point to use a read-only input[type="text"] element here if
> you want to support IE/MSHTML because you need to replace the element in any
> case.

? Not sure to understand. If the user only wants to change a description
in the form (that reflects the content of a record in a database), the
<submit> sends the form with no <file> control, so the CGI server side
only updates the record. If a <file> control is present the CGI takes a
different route, uploads the file, stores the file somewhere and writes
the address to the database etc.

>>>
>>> There is no â??javascriptâ?.
>>
>> ECMA, ok, ECMA.
>
> There is no ECMA (anymore). There are Ecma International, and the
> ECMAScript Language Specification (named for historical reasons). But what
> matters more than the name is the fact that this specification has several
> *different* implementations; several of them have â??JavaScriptâ? in their
> name.

I meant "ECMA" as string substitution of "java". I sould have written:
s/Java/ECMA/

>
> I do not know xbase. ECMAScript is a language of the C family, so you need
> to return a value from a function if you want to avoid an implicit return
> value. The implicit return value is the â??undefinedâ? value in ECMAScript
> implementations.

ACK. See also my answer to Scott Sauyet

Dan

--
"Everybody should pay taxes with a smile"
I tried, but they want money.

danca

7/21/2015 10:30:00 AM

0

Il 07/19/2015 12:59 AM, Scott Sauyet ha scritto:
> Thomas 'PointedEars' Lahn wrote:
>> danca (Daniele Campagna) wrote:
>>
>>> I wrote this small recursive function to find a node (having a name) in
>>> a DOM element:
>>>
>>> //usage: nodeFind (element to inspect (object), f.e. a form, name of the
>>> element to search for, 3rd parameter empty at first call)
>>>
>>> function nodeFind(el,n,retval){
>>> if (el.name==n) {
>>> return (el)
>>> } else {
>>> if (el.hasChildNodes) {
>>> for (var z=0;z<el.childNodes.length;++z){
>>> var a=el.childNodes.item(z);
>>> retval=nodeFind(a,n,retval)
>>>
>>> }
>>> }
>>> return retval
>>> //^^^^^^^^^^^^ note!
>>> }
>> [ ... ]
>>
>>> One strange thing is the way recursion is implemented in javascript: I
>>> did not put the "return retval" statement at first, it seems unuseful,
>>> and went crazy before discovering that it is needed.
>
> That is not really an issue with recursion. This has to do with the way
> Javascript passes values to functions. It uses a specialization of call
> by value, sometimes known as "call by sharing". The reference the caller
> has stored as `retval` is not passed to the function. Instead a *copy*
> of that reference is passed. Both refer initially to the same object.
> But when, inside the function, you reassign the new reference, the caller's reference is left alone. This shouldn't be too surprising if you've dealt
> with languages like Java, Ruby, Python, or even Scheme; they all use a
> similar technique.
>
>
I should have written "the way values are passed to functions".
Unfortunately I don't know any of the languages you are referring to.
In xBase (supposing to have an object mirroring the ECMAscript objects,
and there is none in fact - but it should be possible to create one), I
could have written:

element=nodeFind(el,n)

function nodeFind(el,n)(
local z,a
if el:name==n
return (el)
else
if el:hasChildNodes
for z=0 to el:childNodes:length
a=el:childNodes:item(z)
nodeFind(a,n)
next z
endif
return nil

This function (untested) should return the object (if found) or continue
to call itself and if no match is found the final return value should be
NIL.

Anyway thans for the explanation, that casts some light on the issue.

>> There is no "javascript". [ ... ]
>
> Keep tilting at that windmill. The rest of us know better.
>

:-)

>
> Recursion is logically correct here. If you're working with modern browsers,
> you'll have at least a 20000-call deep recursion stack.. If you have a tree
> that deep in your document, heaven help you. If you have to support IE6 - IE8,
> you'll still get well over 1000 calls deep. I don't know about you, but I've
> never written a document with that much nesting.
>
> A recursive solution is clear and elegant. A non-recursive version would be
> much less so. If you make it tail-recursive, when browsers start to optimize
> tail-recursion, the little performance penalty you would currently pay for
> recursion will be eliminated.
>
> -- Scott
>

"logically correct" is a part of your answer i like very much, but "a
recursive solution is clear and elegant" is what really made my day ;-)

Dan
--
"Everybody should pay taxes with a smile"
I tried, but they want money.

Thomas 'PointedEars' Lahn

7/21/2015 11:54:00 AM

0

danca (Daniele Campagna) wrote:

> Il 07/19/2015 12:59 AM, Scott Sauyet ha scritto:
>> Thomas 'PointedEars' Lahn wrote:
>>> There is no "javascript". [ ... ]
>>
>> Keep tilting at that windmill. The rest of us know better.
>
> :-)

So *that* is what you *really* think. Noted.

>> Recursion is logically correct here.

Nonsense.

>> If you're working with modern browsers, you'll have at least a 20000-call
>> deep recursion stack..

Cite evidence.

And if you are working with not so modern browsers, and not so shallow
documents, which you cannot know because with scripting you do not know the
environment your code will be exposed to, your code will *break*. So
actually you do not need to cite evidence; your argument is that of the
blissfully ignorant again.

>> If you have a tree that deep in your document, heaven help you.

Memory is an issue, too.

>> If you have to support IE6 - IE8,
>> you'll still get well over 1000 calls deep.

It depends not only on the nesting level, but on the stack *size*.

>> I don't know about you, but I've never written a document with that much
>> nesting.
>>
>> A recursive solution is clear and elegant. A non-recursive version would
>> be much less so. If you make it tail-recursive, when browsers start to
>> optimize tail-recursion, the little performance penalty you would
>> currently pay for recursion will be eliminated.
>
> "logically correct" is a part of your answer i like very much, but "a
> recursive solution is clear and elegant" is what really made my day ;-)

You are easily amused. This "logic" is flawed.

--
PointedEars
FAQ: <http://PointedEars.... | SVN: <http://PointedEars.de...
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-...
Please do not cc me. / Bitte keine Kopien per E-Mail.