This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: closures for GOOPS privates
Clark McGrew <mcgrew@ale.physics.sunysb.edu> writes:
> Jost> The problem with this solution is that you can't put the
> Jost> related classes "bike" and "piano" (yes, yes, it's a silly
> Jost> example but I don't have some nice eiffel examples here) and
> Jost> the class "piano-bike" into a single module.
>
> Actually, I keep wondering when (and *why*) you would want conflicting
> classes to be inherited. Everytime I hear this particular argument I
> can help but think, "Bad OOA".
It is not due to bad analysis, there are many real world examples in which
such a conflict can happen. (What´s the translation of amphibienfahrzeug?)
Think about a vehicle that is both a boat and a land vehicle.
I will bring other real examples tomorrow.
Also I don't understand why you think that piano and bike are two
"conflicting classes". In a special design it may be a good idea
to combine them to a single class. The only problem is that they
both have a slot "pedal" and that you must rename either bike's pedal
or piano's pedal to a new name. The module can't handle this, that's
the class' job.
> It's possible that I'm missing something about GOOPS, but it seems the
> Real Problem (tm) is that GOOPS is missing a way to specify a
> particular inherited method (piano::pedal or bike::pedal in c++).
This is usually solved by "feature renaming". Creating a total order
(translation of "Totale Ordnung" :|) by using piano::pedal and bike::pedal
would be a bad idea.
Jost