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

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?

Replies are listed 'Best First'.
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]

In Section Meditations