Re^4: Solving the SUPER problem in Mixins with String Eval

Again, I'm not sure I totally buy it, but it's an interesting idea.

Consider this (thoroughly untested) code:

sub add_stuff_to_file {
    my ($filehandle, $stuff) = @_;
    ($stuff->isa('Iterable')) || die "Stuff must be iterable";
    my $i = $stuff->iterator();
    ($i->isa('Iterator')) || die "Stuff's iterator must be an Iterator
+";
    while ($i->hasNext()) { 
         print $filehandle $i->next();
    }
}
[download]

Now, consider the following code which uses it.

serialize_stuff_to_file(Array::Iterator->new(@array));
serialize_stuff_to_file(ArrayOfArrays::Iterator->new(@array));
serialize_stuff_to_file(ArrayOfHashes::Iterator->new(@array));
serialize_stuff_to_file(Hash::Iterator->new(%hash));
serialize_stuff_to_file(HashOfHashes::Iterator->new(%hash));
serialize_stuff_to_file(HashOfArrays::Iterator->new(%hash));
serialize_stuff_to_file(Tree::Iterator->new($tree));
[download]

Since I know the Iterator will always respond to the same methods, and always produce the expected result on each loop, I can ignore the underlying structure of the object being iterated over. IMO, this is where MJD's argument that foreach is an iterator breaks down.

-stvn

Comment on Re^4: Solving the SUPER problem in Mixins with String Eval Select or Download Code

Replies are listed 'Best First'.
Re^5: Solving the SUPER problem in Mixins with String Eval by simonm (Vicar) on Oct 12, 2004 at 19:38 UTC
Consider this equally untested code: `sub add_stuff_to_file { my ($filehandle, $stuff) = @_; my $i = $stuff->iterator(); while ($i->hasNext()) { print $filehandle $i->next(); } }` [download] Or if you want similar error messages: `sub add_stuff_to_file { my ($filehandle, $stuff) = @_; ($stuff->can('iterator')) \|\| die "Stuff must be iterable"; my $i = $stuff->iterator(); ($i->can('hasNext') and $i->can('next')) \|\| die "Stuff's iterator must be an Iterator"; while ($i->hasNext()) { print $filehandle $i->next(); } }` [download] What is the upside of checking isa when you're deliberately trying to cast a wide net?	[reply] [d/l] [select]
Re^6: Solving the SUPER problem in Mixins with String Eval by stvn (Monsignor) on Oct 12, 2004 at 20:36 UTC
What is the upside of checking isa when you're deliberately trying to cast a wide net? Good point. However with the error message example, IMO checking `isa` is simplier than checking `can` for each method you intend to use, especially when you start getting into a lot of methods (these example interfaces are very simple). Also when an interface is implemented, it is not just about the names of methods, but also the arguments they expect, and values they return. The interface must be implemented as a whole, and not just in parts. Whose to say that `hasNext` and `next` should behave the same across all classes? However, if they both belong to a specific interface, then you know they follow that interfaces guidelines/contract/philosophy. To be honest, the really nice benefits of interface polymorphism come when the language has stricter object type checking and method dispatch based on the full method signature, not just the name. Then you get compile time errors instead. -stvn	[reply] [d/l] [select]


Syntactic Confectionery Delight
	PerlMonks