[1373] in java-interest
Re: "perform:" and Java
daemon@ATHENA.MIT.EDU (Tako Schotanus)
Thu Aug 31 07:57:34 1995
Date: Thu, 31 Aug 95 10:31:31 +0200
To: "John D. Mitchell" <johnm@emf2-003.emf.net>
From: Tako Schotanus <Tako.Schotanus@bouw.tno.nl>
Cc: java-interest@java.sun.com
At 13:59 30-08-95 -0700, John D. Mitchell wrote:
>Tako Schotanus writes:
>[...]
>> If nobody can come up with some serious reasons why *not* to implement it,
>
>This attitude scares me whitless (just like senior citizen drivers :-).
>Just because something sounds neat and useful doesn't mean that it's a good
>idea to add to a language. This attitude is what has brought C++ to the
>horribly obnoxious state that it is today.
*sigh* Okay, here we go again (I warned y'all about this ;)...
The original post was more or less a CFV, wasn't it? It didn't tell me to
explain *why* I wanted a "perform"-type construct, now did it? So in
absense of compelling reasons I'd *really* like to have "perform", just
because personally I see a benefit. I'm currently working on a project
in an OO extension of Tcl which uses exactly this mechanism and even though
I could live without if I ever decided to start using Java (but looking
at the time it takes to come with a beta-release with a good GUI library
I think it'll become C++, which of course doesn't have it at all and
most likely never will) I would still like the freedom it alows me of
extending class interfaces in a class hierarchy without getting a base-
class which is terribly bloated. 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.)
>
>What happened to the lovely concepts that were beaten into us in school?
>Don't criteria like 'necessary & sufficient' and 'orthogonality' mean
>anything to people anymore?
>
>Can't we get some reasonable discussion as to the pros/benefits and
>cons/costs involved in adding/changing [insert topic here] without
>devolving into mindless 'religious' wars and knee-jerk reactionism?
I hope next time you'll just ask people to explain *why* they say something
instead of "accusing" them of something you seem to be doing yourself
as well: "mindless 'religious' wars and knee-jerk reactionism?" Like I said
a CFV is not the same as a RFD if you want a discussion of pros and cons,
say so.
BTW: I *know* the pros (for me, that is) and at least in my post I asked
people to come forward with the cons, as there will no doubtely be
cons, but I just don't know them at this time...
Kind regards,
- 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
