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

[stvn]

I see over-reliance on inheritance as one of the major pitfalls of OO design

Personally, I think that a better more general was to say that is, "The mis-use of inheritance is one of the major pitfalls of OO Design". Over-reliance is only one of the problems out there, under-reliance can be just as bad (when people don't understand when to use it, rather then just not knowing when not to use it).

I agree with a lot of what you are saying, there is far to much inheritance shoehorning going on these days (although that is not really what simonm is doing, you might want to look closer at the implementation in Text::MicroMason (make sure you are looking at the latest developer release)). I have always felt that inheritance is best when it is employed in seperate clusters of shallow heirarchies which (usually) are not related to one another (a.k.a. highly decoupled).

... I can go on further, but in case this doesn't make sense I'll wait and see if anyone understands what I've just said.

What you just described is actually an excellent case for a specific style of inheritance. Interface Polymorphism is IMO of the great underused and misunderstood aspects of OO programming.

To do what you describe (have a MetaThing which takes an array of Things and "runs" each of them in turn) it is usually a good idea to have a common base which all Things are derived from. If for no other reason then for MetaThing to be able to indentify each Thing as a Thing. The knee-jerk approach is to make Thing::Base and have all Things inherit from it. However, this approach limits you in several ways since all your Things must inherit from Thing::Base.

However, a better solution to this all is to create a Thing interface. Then all MetaThing needs to know is that your Thing conforms to the Thing interface, everything else is irrelvant to MetaThing. The idea really is that you try not to program "to the class", but instead "program to the interface". I have found that thinking this way tends to lead to highly reusable code and very clean designs.

[SpanishInquisition]

Yep, we are saying the same thing -- perhaps in different accents, but basically the same thing. At least the way you interpret the Things is the way I meant to explain them. As far as interfaces go, I'm not sure if I agree with the uber-dynmaticity of it all, but that's the way classes in Ruby work...you test to see if something responds to a particular function, rather than seeing if an object is_a particular thing. Again, I'm not sure I totally buy it, but it's an interesting idea.

[stvn]

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();
    }
}

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));

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.

[simonm]

Consider this equally untested code:

sub add_stuff_to_file {
    my ($filehandle, $stuff) = @_;
    my $i = $stuff->iterator();
    while ($i->hasNext()) { 
         print $filehandle $i->next();
    }
}

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();
    }
}

What is the upside of checking isa when you're deliberately trying to cast a wide net?