Collection type javascript library (equivalent to using Blocks) ...

[Lobo]

I'm wondering how expensive and (in)efficient is to use Collection
type javascript library functions (similar to using Blocks), instead
of repeating the 'for' iterator over and over across a large
application.

I'm afraid that instantiating javascript Functions to act as Blocks in
these cases might require many more internal javascript resources
(time / memory) compared to using the 'for' statement - ?.

I would not want this to be the cause for my apps to eventually run
much slower (and consuming more memory).

For reference, define the following Collection type javascript
function:

function array_do (theArray, theBlock) {
for (var i=0; i<theArray.length; i++) {
var eachElement = theArray;
theBlock(eachElement);
}
}

.... and use it as follows:

array_do (testArray, function(each) { ... do something with
'each' ... } );

As you can see I would have to create a new javascript function each
time I need to execute the array_do function.

Thanks in advance.

 

[Henry]

On Feb 7, 3:54 pm, Lobo wrote:

For reference, define the following Collection type javascript
function:

function array_do (theArray, theBlock) {
for (var i=0; i<theArray.length; i++) {
var eachElement = theArray;
theBlock(eachElement);
}
}

... and use it as follows:

array_do (testArray, function(each) { ... do something with
'each' ... } );

As you can see I would have to create a new javascript function
each time I need to execute the array_do function.

No you would not. It would only be necessary to have a diffident
function for each type of action you wanted to perform on each element
in an array, and then pass a reference to the appropriate function to
your - array_do - calls.

 

[Lobo]

On Feb 7, 3:54 pm, Lobo wrote:
<snip>

For reference, define the following Collection type javascript
function:

function array_do (theArray, theBlock) {
for (var i=0; i<theArray.length; i++) {
var eachElement = theArray;
theBlock(eachElement);
}
}

... and use it as follows:

array_do (testArray, function(each) { ... do something with
'each' ... } );

As you can see I would have to create a new javascript function
each time I need to execute the array_do function.

No you would not. It would only be necessary to have a diffident
function for each type of action you wanted to perform on each element
in an array, and then pass a reference to the appropriate function to
your - array_do - calls.

I'm not sure I follow you ...

I want to replace 'for' statements with array_do function calls
without having to do any extra steps (e.g. explicitly define named
functions somewhere), but instead define (and pass) an 'anonymous'
function object directly as the parameter.

I do not want to define external named functions to accomplish this,
but simply use anonymous functions.

My goal is to program more 'object oriented'.

That is, if I understood you correctly - ?.

Let's say I use these 'anonymous' functions all over the system
calling this array_do function thousands of times (therefore creating
thousands of new anonymous functions ?) ... do browsers free resources
(e.g. memory) corresponding to these anonymous functions immediately
after exiting these functions (e.g. array_do)? ... or should I be
concerned about creating these many anonymous functions?.

Thanks again.

 

[Henry]

I'm not sure I follow you ...

I want to replace 'for' statements with array_do function calls
without having to do any extra steps (e.g. explicitly define named
functions somewhere), but instead define (and pass) an 'anonymous'
function object directly as the parameter.

I do not want to define external named functions to accomplish
this, but simply use anonymous functions.

There is a huge difference between having to do something and wanting
to do something.

My goal is to program more 'object oriented'.

What you are proposing here is more functional programming than OO.

That is, if I understood you correctly - ?.

Let's say I use these 'anonymous' functions all over the system
calling this array_do function thousands of times (therefore
creating thousands of new anonymous functions ?)

Yes, creating thousands of function objects, may indistinguishable
from each other.

... do browsers free resources (e.g. memory) corresponding to
these anonymous functions immediately after exiting these
functions (e.g. array_do)?

No, javascript uses automatic garbage collection so you get no more
than resources being freed at some point after the corresponding
objects becoming available for garbage collection.

The details of javascript's garbage collection are left to the
implementers, and so will vary between implementations. Web browser
garbage collection mechanisms have been observed to tend to be low
priority (i.e. slow to react).

... or should I be concerned about creating these many
anonymous functions?.

If you want anything approaching efficiency you should be concerned
about creating all these functions independently of how effectively
they may be cleaned up after you have finished with them.

 

[Lobo]

There is a huge difference between having to do something and wanting
to do something.


What you are proposing here is more functional programming than OO.



Yes, creating thousands of function objects, may indistinguishable
from each other.


No, javascript uses automatic garbage collection so you get no more
than resources being freed at some point after the corresponding
objects becoming available for garbage collection.

The details of javascript's garbage collection are left to the
implementers, and so will vary between implementations. Web browser
garbage collection mechanisms have been observed to tend to be low
priority (i.e. slow to react).


If you want anything approaching efficiency you should be concerned
about creating all these functions independently of how effectively
they may be cleaned up after you have finished with them.

Henry, first of all thanks for all your feedback.

Please confirm or correct: would it be OK then (with respect to
resources - memory / speed -) if I proceed to use the array_do
function with all these anonymous functions as the parameter, or
should I be seriously concerned (assuming this array_do function will
be called thousands of times in one same application)?.

Many thanks.

 

[SAM]

Lobo a écrit :

I'm wondering how expensive and (in)efficient is to use Collection
type javascript library functions (similar to using Blocks), instead
of repeating the 'for' iterator over and over across a large
application.

I'm afraid that instantiating javascript Functions to act as Blocks in
these cases might require many more internal javascript resources
(time / memory) compared to using the 'for' statement - ?.

I would not want this to be the cause for my apps to eventually run
much slower (and consuming more memory).

For reference, define the following Collection type javascript
function:

function array_do (theArray, theBlock) {
for (var i=0; i<theArray.length; i++) {
var eachElement = theArray;
theBlock(eachElement);
}
}

... and use it as follows:

array_do (testArray, function(each) { ... do something with
'each' ... } );

As you can see I would have to create a new javascript function each
time I need to execute the array_do function.

Do not understand your question, that works fine :

function array_do (theArray, theBlock) {
var i = 0, L = theArray.length;
while(i<L) {
theBlock(theArray);
i++
}
}

// test 1 :
var I = ['hello','the','world'];
function tellIt(what) { alert(what); }
array_do (I, tellIt);

//test 2 :
var E = ['body','div','p','ul','li'];
function getLength(what) {
if(document.getElementsByTagName(what) &&
document.getElementsByTagName(what).length>0)
alert(what+' length = '+document.getElementsByTagName(what).length);
else alert('no such tag : '+what);
}
window.onload=function(){array_do (E, getLength);};

 

[Lobo]

Lobo a écrit :

I'm wondering how expensive and (in)efficient is to use Collection
type javascript library functions (similar to using Blocks), instead
of repeating the 'for' iterator over and over across a large
application.

I'm afraid that instantiating javascript Functions to act as Blocks in
these cases might require many more internal javascript resources
(time / memory) compared to using the 'for' statement - ?.

I would not want this to be the cause for my apps to eventually run
much slower (and consuming more memory).

For reference, define the following Collection type javascript
function:

function array_do (theArray, theBlock) {
for (var i=0; i<theArray.length; i++) {
var eachElement = theArray;
theBlock(eachElement);
}
}

... and use it as follows:

array_do (testArray, function(each) { ... do something with
'each' ... } );

As you can see I would have to create a new javascript function each
time I need to execute the array_do function.

Do not understand your question, that works fine :

function array_do (theArray, theBlock) {
var i = 0, L = theArray.length;
while(i<L) {
theBlock(theArray);
i++
}

}

// test 1 :
var I = ['hello','the','world'];
function tellIt(what) { alert(what); }
array_do (I, tellIt);

//test 2 :
var E = ['body','div','p','ul','li'];
function getLength(what) {
if(document.getElementsByTagName(what) &&
document.getElementsByTagName(what).length>0)
alert(what+' length = '+document.getElementsByTagName(what).length);
else alert('no such tag : '+what);
}
window.onload=function(){array_do (E, getLength);};

I'm talking about implementing something like this:

http://www.ejball.com/EdAtWork/CommentView,guid,c2d0f53f-afc7-4831-b60e-f4354ae3f7fa.aspx

In fact a much more complete support is included in the following
javascript framework:
http://www.prototypejs.org/

My question is: if this ForEach function (equivalent to my array_do
function) is called many many times across one application using
_anonymous-functions_ as the parameter, will there be a big penalty in
performance / memory (compared to using simple for loop statements)?.

Thanks.

 

[Henry]

On Feb 7, 11:52 am, Henry wrote:

Henry, first of all thanks for all your feedback.

Please confirm or correct: would it be OK then (with respect to
resources - memory / speed -) if I proceed to use the array_do
function with all these anonymous functions as the parameter,

That would depend on what you defined "OK" to be. I would never even
dream of creating a javascript system to be so inefficient so from my
point of view it is not OK. But if you consider that the vast majority
of people writing client-side code have little or no understanding of
what they are doing, let alone how efficiently they may be doing it,
and that virtually no matter how inefficiently you write something it
will still run predictably (and on a 3GHz quad core with 4Gb memory
probably still pretty fast), that you probably can get away with the
design you are proposing, so that may be, for you, "OK".

or should I be seriously concerned (assuming this array_do
function will be called thousands of times in one same
application)?.

That is going to depend a great deal on your context. If I had written
the client-side code for web applications that I work on as
inefficiently as you are proposing they would be un-sellable. For
simple web page scripts the impact of inefficient code is less
significant (though I quite often find myself smiling at seeing yet
another request for help providing "Loading" or "progress bar" scripts
on AJAX projects when the whole idea of AJAX was that reliability and
compatibility sacrificed in adopting it would be compensated for by
the 'more responsive' UI).

 

[Lobo]

That would depend on what you defined "OK" to be. I would never even
dream of creating a javascript system to be so inefficient so from my
point of view it is not OK. But if you consider that the vast majority
of people writing client-side code have little or no understanding of
what they are doing, let alone how efficiently they may be doing it,
and that virtually no matter how inefficiently you write something it
will still run predictably (and on a 3GHz quad core with 4Gb memory
probably still pretty fast), that you probably can get away with the
design you are proposing, so that may be, for you, "OK".


That is going to depend a great deal on your context. If I had written
the client-side code for web applications that I work on as
inefficiently as you are proposing they would be un-sellable. For
simple web page scripts the impact of inefficient code is less
significant (though I quite often find myself smiling at seeing yet
another request for help providing "Loading" or "progress bar" scripts
on AJAX projects when the whole idea of AJAX was that reliability and
compatibility sacrificed in adopting it would be compensated for by
the 'more responsive' UI).

All your feedback is really appreciated.

Thanks.

 

[dhtml]

All your feedback is really appreciated.

What you're trying to do is "write the loop once". This is basically
Template.

It's DIP, or IoC. It's similar to Command, or Strategy, or any
behavioral pattern in that way.

The big difference here is that functions are objects in JS, so no
need to create any IteratorCommand or anything.

Try looking at Array.forEach in JS 1.6.

http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Objects:Array:forEach

 

[VK]

I'm wondering how expensive and (in)efficient is to use Collection
type javascript library functions (similar to using Blocks), instead
of repeating the 'for' iterator over and over across a large
application.

Collections and blocks (as defined in your post) are from ol' good
linear programming. In OOP you are having a set of objects with
particular methods and properties and you are calling the necessary
method. If you don't need to keep particular data in each method for
each object instance then we define the method as static so no matter
how many object instance are created, they all will be using the same
scavenger (heap?)
In your case (if it is your case) that might be:

function MyObject {
// per-instance
// methods and properties
}

MyObject.prototype.staticMethod = function() {
// this.doSomething
}

and then could be

for (var i=0; i<myObjectsArray.length; i++) {
myObjectsArray.staticMethod();
}

this way if cannot tell before runtime what kind of staticMethod you
may need and either it can be static or not: that would mean that your
OOP schema has a failure in it or not ready yet so it needs more
thinking over before implementing.

There is nothing criminal in using the old linear programming
approach, I just wanted to stress out that what you are doing is not
OOP.

As you can see I would have to create a new javascript function each
time I need to execute the array_do function.

Not in OOP