the foreach instruction

[ConvertFromOldNGs]

by JADE Kid - Ray Hidayat >> Tue, 9 Jan 2001 1:43:06 GMT

Currently, if I go:

foreach fileFolder in fileNodeArray do
endforeach;

Jade will come up with an error. That is a bit annoying. As we all know, the FileFolder class is a subclass of FileNode.

So what should happen is Jade should work out exactly which of the references in fileNodeArray are FileFolders. Don't you agree?

--
Ray Hidayat
JADE Kid - 2000
www.jadekids.com

[ConvertFromOldNGs]

by Craig Shearer >> Tue, 9 Jan 2001 18:42:58 GMT

Hi Ray

This is an interesting idea, but I'd be against having JADE implement this version of foreach mainly for efficiency reasons - it would encourage laziness on the part of developers.

Imagine the collection is huge (perhaps not for a collection of file folders, but perhaps customers). Since the collection is unlikely to be keyed on the type of object, no optimisation would be possible - it would be a sequential search through the whole collection to find the correct object types.

Eg.

foreach specialCustomer in allMyCustomers do

endforeach;


if allMyCustomers contained 20000 Customer objects, and 500 SpecialCustomer objects this would be pretty inefficient!

I think that if you did want to do this sort of thing then it would encourage you to find a collection that contained only the types of objects you actually want to deal with, or realise the overhead in your code.

My other reaction to this is that the construct is probably dangerous anyway. At least as it is at present, the variable to contain each object in the collection must be completely compatible with the collection membership. It would be easy to introduce an error in your code by using a variable of a subclass type rather than the type of the collection and thus JADE would automatically do a hidden search and you wouldn't even know it was happening.

So, I'd prefer to leave it the way it is now.

Craig. (in Auckland where it's cloudy, and going to rain, and I don't have my umbrella!)

[ConvertFromOldNGs]

by Wilfred Verkley >> Tue, 9 Jan 2001 23:00:10 GMT

This is an interesting idea, but I'd be against having JADE implement this version of foreach mainly for efficiency reasons - it would encourage laziness on the part of developers.

And reduce the type-checking just encouraging us lazy programmers to make more mistakes.

And BTW, how hard is this?

foreach fileNode in fileNodeArray where fileNode.isKindOf (FileFolder) do fileFolder := fileNode.FileFolder;
endforeach;

Wilfred.

(In Auckland, where its Cloudy and i hope it rains)

[ConvertFromOldNGs]

by David Mitchell >> Thu, 11 Jan 2001 1:51:20 GMT

And BTW, how hard is this?

foreach fileNode in fileNodeArray where fileNode.isKindOf (FileFolder) do fileFolder := fileNode.FileFolder;
endforeach;

I seem to remember that the where clause is quite highly optimised for only one condition as long as it doesn't call a method (ie it is only accessing a property on the object). I am not certain, but if this is true then it would be a considerable performance boost to change the above to:

foreach fileNode in fileNodeArray where fileNode.class = FileFolder do
....
endforeach;

Just don't quote me on that.
David Mitchell

[ConvertFromOldNGs]

by Michael Jones >> Thu, 11 Jan 2001 2:11:59 GMT

For performance, I imagine a straight class comparsion would be quicker, but the situation would generally dictate which expression would be used. For generic methods ,designed to be reused by subclasses, IskindOf
would be ideal. This is because a class comparison only catches the instances
of the particular class, whereas isKindOk catches all subclass instances.

[ConvertFromOldNGs]

by Krull >> Thu, 11 Jan 2001 3:39:32 GMT

I seem to remember that the where clause is quite highly optimised for only one condition as long as it doesn't call a method (ie it is only accessing a property on the object).

Hi David,

The compile time 'where clause' optimisation you are thinking of is actually more specific than that. It only applies when iterating a single-key dictionary when the where clause consists of a simple relative key expression e.g. obj.memberkey1 > value1. Multi-keyed dictionary iterations and more complicated expressions including ranges e.g. key1 > lowerValue1 AND key1 < upperValue1 are not currently optimised. Consider, for example a foreach statement of the form:

foreach o in dict where o.key <rel op> searchkey do // <rel op> is > or >=,
. . .
endforeach;

or in a reverse iteration:

foreach o in dict reversed where o.key <rel op> searchkey do // <rel op> is < or <=
. . .
endforeach;

These cases are optimised by the compiler to use the Iterator::startKey<rel op> methods to start the iteration at the first entry in the dictionary satisfying the search condition. Remember that the JADE foreach statement is simply 'syntactical sugar' for an iterator loop so any further optimisations the compiler or a separate backend query optimiser could do for you can be coded manually using Dictionary/Iterator relative key methods and suitable termination conditions.

[ConvertFromOldNGs]

by JADE Kid - Ray Hidayat >> Thu, 11 Jan 2001 5:57:20 GMT

I completely forgot about the where clause. I hardly ever use it. Now I realise how useful it is.

--
Ray Hidayat
JADE Kid - 2000
www.jadekids.com