[Prev][Next][Index][Thread]
Re: Fw: Fw: Beyond Java?
Jason Trenouth wrote:
> From: Maxim Kizub <M.Kizub@post.skynet.lt>
> > 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.
This is not 100% accurate from the Dylan programmer POV.
Most classes in an inheritance graph will benefit from the
direct access optimization due to the simplicity of the graph.
The "primary" adjective is a restriction you may want to
impose on the inheritance graph to make sure that this optimization
is always available to subclasses.
It is an advanced feature for discerning programmers :-).
> >
> > 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.
> >
> > So, whenever developer will need 'delegation' kind
> > of inheritance - dylan will be slower, then
> > it's possible.
How would it be faster to use the forwarding technique
rather than writing a simple forwarding method (which
can be inlined in about the same cases where the forwarding
could be optimized) ?
> > 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.
"final" and "sealed" are really different beasts. Sealed
let you extend the class/method in the current module.
In many cases this is all you need. Final doesn't allow
_any_ further extension and it is too limiting.
Moreover "sealed domain" allows partial sealing of methods.
As a Dylan programmer I found that very often sealed domain
is all you need to get compile-time dispatch resolution
and leaves the G.F. open to "natural" extensions (ie extensions
that make sense).
> > 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.
> >
> > 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' :-(
Maxim, no disrespect intended but most of the arguments
you use against Dylan really show one thing, which is that
you haven't practiced Dylan much.
Multiple dispatch is typically optimized away. If not then
it probably means that the design calls for it and the same
design would be slow in C++/Java too.
Same thing for multiple inheritance. Dylan got it right. Still
it is only called for in relatively rare situations and then
it is better suited than delegation. When delegation is better,
Dylan allows it.
In the same way primitive types as objects are really better
than Java's Integer,... when you need them. When you don't then
typically the compiler will optimize the costs away. I'd still
love Dylan to have a standardized way to deal with raw values
(8,16,32,64 bits signed/unsigned) in a fast and easy way, but
the uses I have for those would most of the time be separate
from the uses I have for <integer>. And it is only because my
day job involves very low-level code. In "application" programming
those needs are typically less frequent.
Unfortunately I find that Dylan qualities are really hard
to explain or advocate. To me Dylan advances are more of the
"you need to experience it" kind, subtle and often counter-intuitive
to C++/Java programmers. I fear that this slowed the language
adoption quite a bit.
Regards - Eric
(Jason, please feel free to post this to c.l.dylan if you do not see
it appearing in a couple of days, I am wondering if my posts make
it to usenet)
References: