[Prev][Next][Index][Thread]

Re: [Q]Why are all classes rooted by <object>

On Sat, 28 Jul 2001 22:45:01  
 Eric Gouriou wrote:
>Brad Settlemyer wrote:
>> Well, the subject pretty much says it all, but can anyone explain the 
>> rationale behind making all classes implicitly derived from <object>.
>> 
>> Dylan appears to me to be suitably generic not to need this artifice (Java, 
>> for example, is not).  What am I missing?
>
>  That it is quite important to be able to declare
>methods that can operate on *any* object a program
>will use.
>
>  define generic xml-encode (obj :: <object>) => (xml :: <string>);
>
>  define generic write
>      (stream :: <stream>, obj :: <object>)
>   => (str :: <stream>);
>
>  define generic \= (obj1, obj2) => (equal? :: <boolean>);
>  (here <object> is only used implicitly, but it is still used)
>
>  Without a unique root it would be quite difficult to get such
>functions to work. You could then argue that this root does not
>need an explicit name, but then giving it a name has no drawback
>I can see.
>
>  It may not be the whole story and I hope others will complete it,
>but IMO that may be the most important aspect.
>
>  Regards - Eric

One way to think of this is to pose the opposite question: what is
the benefit to having some classes that don't derive from <object>?
I can't think of a benefit, it seems to me to only produce a more
complicated user model. Do you have a benefit you are thinking of?
Or do you have a language in mind that supports your ideal model?

A simple example of the benefit to the Dylan model is that the
Dylan collection API allows you to have collections of anything.
e.g. there are no restrictions as to what you can put in a vector.
This is in comparison to Java, which has to provide vectors that
support primitive types (i.e. arrays) and vectors that only support
objects (i.e. vectors). Real world Java code is filled with coercions
between primitive integers (int) and object integers (Integer),
which you never see in Dylan. [I realize you already discounted
Java's model, it is just the easiest comparison to make].

A lot of the benefits are to be found in the 'higher order'
language constructs, such as 'map', 'curry' etc. These functions
can work with integers or arbitrary objects just as easily:

  map(double, #[1, 2, 3]) 
    => #[2, 4, 6]

  map(as-uppercase, #["hello", "world"])
    => #["HELLO", "WORLD"]

  map(window-color, window.window-children)
    => #[#x00FF00, #xFF0000, #x0000FF]

Languages that don't have this clean model appear to always do so on
the grounds of efficiency, not for any other reason [at least,
in my experience]. Dylan achieves the same efficiency by making
the compiler work harder, rather than forcing the user to have to
use a more complicated, split world model.

Does that help explain the thinking behind it?

Andy

---
Andy Armstrong
andrewa@functionalobjects.com



Get 250 color business cards for FREE!
http://businesscards.lycos.com/vp/fastpath/