in reply to Re^3: Solving the SUPER problem in Mixins with String Eval
in thread 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

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]
      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]

In Section Meditations