Re: What should the criteria be for adding methods to the base classes?

"Eliot Miranda" <eliotm@xxxxxxxxxxx> wrote in message
news:UaY0f.1300$we3.242@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> what you say about overrides makes perfect sense. There's a clear
> need to describe potential conflicts and warn appropriately.

Any chance of something actually happening on that? 7.4.1? Unlike what
follows, this is a nicely bounded improvement that doesn't require a
PhD project to figure out what we want :-).

> But there is a subset of override cases, your case 2) where each
> adds a different improvement to the same base method, where
> something akin to lisp-style method combination could work. Here's
> an example extracted from a workshop paper I brought to oopsla '98.
[snip]
> One promising idea is a calculus of override composition,
> reminiscent of method combination in CLOS [Bobrow88]. Here one
> could specify how to edit a method into some base method such that a
> functional aggregate could be formed. The annotation approach for
> menus above seems adequate and adaptable to this case. CLOS's
> method combination semantics are a suitable starting-point. The
> application of such a scheme in the above example might look like:
>
> Skeleton implementation of Object>>#become: in event-based
> dependency component:
> become: otherObject
> "annotation informing loader that a merge is required"
> <methodExtension>
> | myEvents itsEvents |
> myEvent := self myEventTable.
> itsEvent := otherObject myEventTable.
> "annotation that invokes existing method"
> <innerMethod>.
> myEvent == itsEvent ifFalse:
> [self myEventTable: myEvent.
> otherObject myEventTable: itsEvent].
> ^self

Neat! I could do that already in a few different ways with standard
Smalltalk, but a good syntax and mechanisms for ordering the execution
of the extensions would help. Still, I'm not sure we really want it:
it might be more appropriate in base classes or frameworks, as a way
of adding hooks for code built on them to use, but even then it would
only really be most useful in languages like Java where the base
methods can't be overridden or changed.

So whilst I honestly think this is neat, and admit to being attracted
by solutions like this, the pragmatist in me says it's really quite
rare that I want to override a base method (other than as a bug
correction prior to Cincom integrating the correction). And only maybe
twice in thirteen years of Smalltalk have I encountered a case where
there were two distinct overrides to the same base method. In neither
case did I feel that I would have wanted a conceptually sound solution
that would have enabled a third, fourth... nth override/extension to
the same piece of code.

In addition to fairly standard Smalltalk solutions (e.g. having a
collection of CompiledCode at each extension point, stored in a shared
variable), and meta-programming solutions (e.g. grouping methods to be
executed for each extension point into a separate protocol for each
point), VW also offers pragmas (which could be used to mix in
behaviour, as for menus), and events (OK, so they probably count as
standard Smalltalk). I'm not sure I'd want to burden new developers
with learning yet another mechanism and syntax.

I've never had the pleasure to program in CLOS, but would it work to
use pragmas for this? Each method wanting to be inserted at the
<methodExtension #pre> point above would be defined in the same class,
with pragma <#become: #pre>. We could have some standard set of
pragmas (e.g. precondition, enter action, return value manipulation,
exit action, postcondition - oops, looks like I'm reinventing
MethodWrappers!), in which case the main #become: method wouldn't even
need a pragma, and/or have standard Smalltalk calls in the body of the
main method: "self extensionPoint: #pre", where the name is freely
chosen there and extenders must match it in their pragma.

Now what would be really cool was if the extension methods (method
fragments?) could have access to the main method's arguments and
temporary variables, would run with its scope (e.g. return, error
blocks), and could be shown and edited in the IDE integrated into the
main method (with a different background colour or something). Like
you said, this would be based on the parse tree, so should be
possible.

This - and previous threads here or in vwnc about doing away with
source text and just having the (slightly annotated) bytecode - is all
starting to sound like Intentional Programming. Smalltalk is uniquely
placed to implement IP, since the code is "live" in the image. But
this waffle is already too long, so I'll stop here :-p

Steve


.

Relevant Pages

  • RE: What is the difference between new and override
    ... > But what is the difference between new and override? ... intuition that might help. ... If we put a method in a derived class that hides a base method, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Petzold Assumed I Could Figure It Out -- I Am Stumped
    ... Petzold was greatly enhancing the flexibility of the DLL contained ... commented out the base class call in the override and ran it. ... the base method in this particular program does nothing ... ... I had been frozen in confusion and now can move forward. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: feature question
    ... a base method BM with signature "C M;" ... an override OM with signature "D M;" ... DerivedFactory GetFactoryin the DerivedObject class ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Overriding methods but force base classs method to be called.
    ... or even suggesting a better/different way. ... public override void Validate() ... will call the base method, ... overrides Validate to have to call base.Validate or their class won't ...
    (microsoft.public.dotnet.languages.csharp)