[1377] in java-interest
Re: "perform:" and Java
daemon@ATHENA.MIT.EDU (Tako Schotanus)
Thu Aug 31 11:30:46 1995
Date: Thu, 31 Aug 95 14:05:27 +0200
To: "John D. Mitchell" <johnm@emf2-003.emf.net>
From: Tako Schotanus <Tako.Schotanus@bouw.tno.nl>
Cc: johnm@emf2-003.emf.net, java-interest@java.sun.com
At 02:06 31-08-95 -0700, John D. Mitchell wrote:
>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.
Yes, possibly my object model is broken (with my limited experience in OO
programming I would even consider it likely ;), but at this particular
moment I don't see another solution.
I also don't see what could be wrong with an object model that has a lot
of specialized objects and code that might use a specialized method without
actually knowing if the object supports it. In an environment with a lot of
user-interaction, for example a program with a GUI that let's you handle
the objects in an interactive manner or for example a MUD (I wrote a simple
one once to see if and how an OO aproach would simplify things) where a user
would be able to type any kind of command (a method) acting on any kind of
object.
But of course there might be a perfectly good solution to these kind of
problems. I just don't know them (I always thought they didn't spent enough
time on OO subjects at my institute :( )
On the other hand: if after such a time people are *still* discussing it in
comp.object.* I think even the experts are not agreeing, so how can we?
So again I say: if somebody has some *good* reasons for not wanting "perform:",
please tell us, because then and only then can we form an educated opinion.
But until then I think it's enough for me to say that I'd like the feature
without going through this trouble every time explaining my motives. SUN's
people have already devoted quite some time to this subject, so probably they
liked the feature and really wanted it, but finally it turned out to be
quite difficult to implement. People like me saying they would like to see
the feature, if it's not too difficult, might be a reason for them to take
a second look, I doubt though if they would want to know *why* I want it ;)
>[...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.
Aah! So for everone's benefit you've taken the discussion to e-mail? But not
without first remarking that the rest of what I said was "Yet more petty BS"!
>
>Thanks,
> John
Yes, thank you very much indeed :(
- Tako
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
_/ Tako Schotanus, TNO Bouwinformatica _/
_/ work: Lange Kleiweg 5, 2288 GH, Rijswijk, NL, tel: +31-15-842393 _/
_/ home: van Hasseltlaan 352, 2625 HZ, Delft, The Netherlands _/
_/ E-mail: sst@bouw.tno.nl - URL: http://huizen.dds.nl/~quintess _/
_/ Never let a dictator rule with peace; let peace rule like a dictator _/
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
