[Prev][Next][Index][Thread]
Fw: Fw: Beyond Java?
----- Original Message -----
From: Scott McKay <swm@mediaone.net>
To: Jason Trenouth <Jason.Trenouth@bigfoot.com>
Sent: Sunday, March 18, 2001 9:50 PM
Subject: Re: Fw: Beyond Java?
> -----Original Message-----
> From: Jason Trenouth <Jason.Trenouth@bigfoot.com>
> Newsgroups: comp.lang.dylan
> Date: Sunday, March 18, 2001 2:53 PM
> Subject: Fw: Fw: Beyond Java?
>
>
> >
> >----- Original Message -----
> >From: Maxim Kizub <M.Kizub@post.skynet.lt>
> >To: Jason Trenouth <Jason.Trenouth@bigfoot.com>
> >Sent: Sunday, March 18, 2001 12:10 PM
> >Subject: Re: Fw: Beyond Java?
> >
> >
> >> Hello Jason,
> >>
> >> I investigated multiple inheritance in Dylan, and
> >> have found, that it's not as efficient as can be.
> >>
> >> Let me demostrate why. First, if you remember, in
> >> my kiev comopler I added two forms of multiple
> >> inherotance - via interfaces and via delegation.
> >>
> >> For interfaces I added ability to have "virtual"
> >> fields, i.e. ability to define a getter and setter
> >> pair of methods, and syntax sugar to use them
> >> as fields. For example
> >>
> >> interface I {
> >> virtual int i;
> >> int mul(int j) { return i*j; }
> >> }
> >>
> >> which will be translated as
> >>
> >> interface I {
> >> int get$i();
> >> void set$i(int val);
> >> static mul(I this, int j) { return this.get$i() * j; }
> >> }
> >>
> >> I noticed, that Dylan has two forms of clases.
> >> Those that called "primary" - can access own fields
> >> like java classes (i.e. fast direct access), and
> >> others - only via getter/setter methods, exactly like
> >> in my interfaces with virtual fields.
>
>
> Just to correct a detail, *all* Dylan slot access is through
> getter/setter methods. In two cases, slot access can be
> highly optimized:
> - when the class is primary
> - when the class is sealed
>
> It is not the case the fast slot access can be done only
> when the class is sealed. To be perfectly honest, the
> optimization for sealed but otherwise not-primary classes
> is a bit tougher, and I don't know what compilers do it.
>
> >> But I have defined another way - delegation.
> >> For example
> >>
> >> class C {
> >> forward Named name;
> >> }
> >>
> >> will delegate all calls to 'Named' methods to
> >> field 'name'. Sometimes you do not need that
> >> implementation of Named will call any methods
> >> of class that extends it - in this case instance
> >> of Named will be able to access it's fields
> >> in the same direct and efficient way as "primary"
> >> classes.
>
>
> Surely this cannot be exactly as efficient, because you have
> to go through two instances to get to the slot. That is, somewhere
> you must follow an extra pointer. You can do delegation as
> efficiently in Dylan as in any other language, but with the same
> failure as in any other language. (That failure mode is, "what
> is the value of 'this'?". Unless you keep track of the "parent
> object", you can't tell who 'this' is.)
>
> >> So, whenever developer will need 'delegation' kind
> >> of inheritance - dylan will be slower, then
> >> it's possible.
> >>
> >> And a few words about optimization of libraries.
> >> To be able optimize method dispatching you need
> >> to declare Dylan's classes and functions to be closed
> >> (not allowed to be extended). The same issue is
> >> solved in java by having 'final' classes and methods.
> >> And optimized compiler may inline small methods
> >> of final classes or final and private methods,
> >> plus JIT compiler can (and do) dispatch calls
> >> to those methods as direct calls, not via
> >> virtual table.
>
>
> As does Dylan. In the absence of good type information at
> JIT time, I don't see how JITs can do a really good job. I
> personally think that JITs are a really stupid idea, even tho'
> I think the problems that need to be solved are interesting.
>
> >> So, I think that there is no magic in Dylan about
> >> ability to optimize multimethod calls in libraries,
> >> except library designer will makes most of classes
> >> 'final' :-(
>
>
> Not true. The classic Dylan technique for this is to make an
> exported abstract open class, an unexported sealed subclass,
> and a 'make' method on the open class the creates an object
> whose type is the sealed final class. The compiler sees that
> the sealed 'make' method returns the sealed subclass, and
> can optimize accordingly.
>
> DUIM uses this technique all over the place to get both
> extensible framework classes and good optimization for the
> usual case.
>
> This is obviously not "magic", but it does not require that
> the library designer make the exported classes be final.
>
>