Re: [CLOS] Ensuring a method exists



Christophe Rhodes wrote:
Ken Tilton <kentilton@xxxxxxxxx> writes:


Of course the big question no one will ask is why you want to do
this. Sounds like bad design. But you are not alone, we get people
wanting to do this almost as often as we get people trying to fix the
parens.


I'm not so certain that this kind of thing is necessarily bad design.
I think that CLOS's generic functions and class inheritance provide
good ways of adding functionality ("extending", if you will) by
subclassing; what I think is harder to express in vanilla CLOS is
removal of invariants, or generalization of functionality.

To take a concrete example, consider implementing a data structure
such as an R-tree, which has a relatively complex set of invariants
that you might want to assert are true at various points in the
protocol. Then you implement a variant, such as the R*-tree, which
obeys the same protocol, and indeed shares much of the implementation,
but has slightly different (but overlapping) invariants. How do you
model that, with just CLOS? Probably what you do is define some kind
of abstract base class and make R-trees and R*-trees inherit from that
base class, but now you can't share the methods that actually should
be shared:

Oh. Why not? Don't see that from the set-up above. And, whatever it is, multiple-inheritance won't help? If not, sounds like classes and the very idea of OO are simply the wrong hammer for this problem, and it might be wiser to byte the bullet and use macrology and the DSL thing to Just Say What We Mean.

Now maybe that is what is going on and the OP is just leveraging CLOS as a convenient internal tool to the larger API, but then that is why I suggest going /further/ and hide the CLOS behind some macrology, at which point the OP can enforce anything they want really really easily (instead of staring at AMOP looking for support for something not really OO-able).

instead you have to implement the methods separately,
admittedly maybe with a call to the same function. So sometimes I
think it makes sense to want to treat direct instances and general
instances of a class differently: it allows you to express things in a
way that is closer to the application space (which is what we're
aiming for, right?)

Well, I'm not smart like you guys, I can only think in concrete, so I kinda would have to see the actual use case.*

kt

* I get a kick out of it when people respond "oh, sure. here ya go. there's this class foo, see, and this other class bar, and...". :) k

--
Cells: http://common-lisp.net/project/cells/

"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
.

Relevant Pages

  • Re: [CLOS] Ensuring a method exists
    ... I'm not so certain that this kind of thing is necessarily bad design. ... removal of invariants, or generalization of functionality. ... base class, but now you can't share the methods that actually should ...
    (comp.lang.lisp)
  • Re: Language improvement: Add scope to class member fields
    ... every small subset of functionality into seperate classes. ... MyMethodwould check this flag first within a lock and only run the method ... currently stands there is no protection. ... Allowing classes to become more complex is not a terrific design goal, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: news of the week
    ... And as market leader, that company does not have the time to listen to ... When I designs a website, I constantly have to think about why ... didn't design the website for me. ... offers the same functionality, yet. ...
    (rec.games.computer.ultima.dragons)
  • Re: Is it possible to use the value of the PROGRAM ID within the source code?
    ... Mr Wagner, structured design, as I understand it, is functional ... object oriented design is closer to the idea of functional cohesion, ... If functionality is likely to change, ...
    (comp.lang.cobol)
  • Late Show Fashion #2510
    ... "I have little interest in design. ... I hate placemats that ... Okay all good design is based upon functionality. ... aesthetics, functionality, and comfort. ...
    (alt.fan.letterman)