[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Article for Slashdot: Oracle for Java
On 07-Sep-98 Stanislav Malyshev a.k.a Frodo wrote:
>> Anyway, the point is Java as language ( not platform ) has "clean" design
>> and Perl does not have design at all :{)
>
> Tell this to Perl developers and then duck and run really fast. The fact
> that no multi-billion corporation has control over it and that no
> PowerPoint slides were ever presented to endless groups of pointy-haired
> managers doesn't always mean there was no design.
Although the "no design at all" is a bit wildy, the fact is that Perl is
**designed** not to have "design". If you take "There's-More-Than-
One-Way-To-Do-It (TM)" moto and the strange operators like '..' (in scalar
context) you see that (as Larry Wall said) the aim was to create practical tool
for day to day tasks rather than create a "clean" design (In daily jobs the
'..' operator is really usefull).
> And no, from the OO point of view Java does not have "clean" design. As
> almost no other real life language does - "clean" OO is a bit restrictive.
> If you mean some other "clean" design - explain. Also how come that after
As with any language it is important not to mix the language itself with its
standard libraries...(read ahead).
> this "clean" design next sub-version (1.1) has entirely different event
> model, for example? Which design was bad? Or maybe they was just a bit too
> hasty to push underdeveloped product on market? We know some companies
> doing this constantly, why not Sun?
Now, you are jumping a bit high:
1. JDK-1.0.x event model was based on inheritance which is "clean" OO
design. However, since inheritance is static (compile time) it is
not flexible enough for some real life situations (e.g: if you want
your GUI to change in run time).
2. JDK-1.1.x event model is basically a callback mechanism (so it's
less OO-clean). However, it is different than traditional callback
mechanisms (e.g: Motif (sorry Eli :-)) in that the registration of
callbacks is done with type safety - an object **cannot** register
to an event type if it is not ready (has the methods) to receive it.
This feature is checked during compile time. Another "clean" issue
in this design is that a third party may register a receiver object
to a sender object at run-time even if the objects don't know about
each other beforehand (and still guarantee type-safety at compile
time).
So, life is more complicated than black/white (1.0/1.1)
----------------------------------------------------------------
Oron Peled Voice/Fax: +972-4-8228492
oron@actcom.co.il http://www.actcom.co.il/~oron
"To err is human, to really fuck things up takes root.... except on
Windows, where everyone is root."