[1374] in java-interest
Re: "perform:" and Java
daemon@ATHENA.MIT.EDU (John D. Mitchell)
Thu Aug 31 08:47:12 1995
Date: Thu, 31 Aug 1995 02:06:22 -0700
From: "John D. Mitchell" <johnm@emf2-003.emf.net>
To: Tako Schotanus <Tako.Schotanus@bouw.tno.nl>
Cc: johnm@emf2-003.emf.net, java-interest@java.sun.com
In-Reply-To: <9508310831.AA02186@hermes.bouw.tno.nl>
Tako Schotanus writes:
[...See Note at bottom of post...]
> I'm currently working on a project in an OO extension of Tcl which uses
> exactly this mechanism...
[...]
> In my project for example I have some objects that are all subclasses
> from a common base-class, they have a lot of code in common, but it's
> also possible that a specialized object has some method that is used only
> for a certain job. Now there are I think three ways of doing this:
> - virtual functions all the way : if you have a lot of those specialized
> methods after a while you'll have a base-class that's really big, but
> contains mostly stubs. Secondly, you'll have to change the base-class
> every time you create such a specialized method, which is something
> you might not want or are not even able to do! (Personally I just
> don't like my base-class cluttered with methods that have nothing
> to do with the (abstract) idea that my base-class is trying present)
> - meta information : write a method so you can ask the object which class
> it "belongs to" and keep a table in your invocation code that "knows"
> which type supports the specialized method. (Or you could register all
> specialized methods and ask an object which ones it supports, but that's
> almost the same as a "RespondsTo:" and "perform:" pair, isn't it? ;)
> Again the problem is that for every new object or specialized method
> you need to change code in all kinds of different places
> - "RespondsTo:" - "perform:" construct : you simply ask the object if it
> supports the method and call it if it does. (Of course the previous
> example is the same, but you'd have to do it all yourself, better let
> the language handle it. That way you can cut down on bugs as well
> because the compiler never "forgets" to change an entry in its
> tables.)
Well, hmm... I can see this as a possibility but it seems to be a case that
is nearly constantly being argued in comp.object... If the base class is
really gaining methods that "have nothing to do with the (abstract) idea"
of the base class then your object model seems very likely to be broken.
The use of respondsTo:/perform: in this case seems like a cheap hack to
'fix' the broken object model rather than a preferred design solution.
Though it seems possible that if there is good reason for this particular
object model then the respondsTo:/perform: is a reasonably slick solution.
[...Yet more petty BS...]
Note A: For the benefit of everyone involved I have taken the 'discussion'
of the elided material of Tako's post to direct email.
Thanks,
John
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
