Re: object system...

On Tue, 6 Jan 2009 01:08:54 +1000, cr88192 wrote:

but, oh well, I figure I will present some of the ideas behind an object
system I had implemented and am making use of in my projects, and maybe
people can comment if some things are good or not so good.

basically, the core of the system is this:
Single-Inheritance Class/Instance OO (MI is more-or-less supported as well,
but it is hacky and not well supported by the APIs, so I mostly ignore MI);
there are Interfaces, like in Java and friends;
...


but, it differs from the normal model some in a few ways:

interfaces can implement slots as well as methods;

Slot = member? Implemented as a getter/setter pair?

it is technically possible to use any interface with any compatible class
(due to a side effect of how the interface mechanism is implemented, the
same interface will work on a class regardless of whether or not said class
implements the interface as such);

Egh? Does it mean that there is no manifested declaration that a type
implements the interface, so that anyone can call anything on everyone?
Looks like a mess.

it is possible to modify class layout at runtime, and the object system
machinery will work to keep everything consistent (internally, a versioning
system is used, so an older object may be layed out according to an older
version of the class), however doing so will reduce the performance of the
class(es) in question;

Do you mean representation in the memory? Why do you want to modify it? It
does not look like a workable idea when considering packed containers etc.
For instance an array of Booleans.

it is possible to add slots to individual instances of an object, allowing
the emulation of some aspects of Prototype-OO style

What for?

(as well as the ability to "clone" objects, ...),

You mean a polymorphic copy? Where is a problem? Except that one must
separate classes and types in order to be able to do so. Does your system
separate them?

there is also support for object delegation (like in Self or JavaScript),
but this feature can at present only be used via interfaces (this is mostly
for technical reasons);

I see, delegation when there are interfaces to members looks technically
easy. The problem is syntax sugar for.

there is also support for special assignable methods, which exist in the
instance rather than in the class (the method is actually directed through a
slot rather than through the vtable).

Shudder. Methods do not exist in either. Vtable is a poor design. What
about a sane multiple dispatch instead of the mess.

so, in short, for many tasks it is necessary to make use of an interface
rather than the direct physical class (but, as a cost, accessing a slot or a
method via an interface is slower than accessing it directly).

In my view interface as a separate concept brings only disadvantages. There
should be only types and classes of.

I did check before, but with my model it is possible to make use of many of
these features while still being within the realm of what could be
statically proven to be correct (although keeping things statically provable
would place many other restrictions on everything as well, for example,
placing restrictions on which objects can be assigned to which interfaces,
either by requiring the class to 'implement' the interface, or by validating
that the class is compatible with the interface, ...).

It is not clear what features you mean. Many of them are implementation
issues.

For static analysis, it is important to have a manifestedly typed system +
fine grained types. If you throw everything into one type-class there is
little one could check in the end.

performance could be better, but it is still "acceptable"...

What I expect from a good system is zero performance hit when no dispatch
happens. This is why type/class separation is so important to me. If you
deal with only types, which is about 80-90% of all calls, you do not need
to dispatch and so there is no any overhead (the target is statically
known).

Another requirement is that dispatch never fails, i.e. classes are
statically checkable.

Yet another is hard read-time constraints of call overhead.

note that a major central structure in the object system is a few large hash
tables, which are the primary means by which things like interface lookups,
... are performed (hashes are computed using the classname, slot/method
name, and method signature, ...).

Performance of hash tables is less predictable, you cannot actually tell
how long it would takes to call a method if that goes trough a hash table.
But in the first place I don't see why it should. IMO this stuff should not
leak beyond the compile time.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
.

Relevant Pages

  • Re: object system...
    ... In a typed system you can separate implementation from the interface ... How to express in the language a wish to delegate, A of X to B of Y. ... Performance of hash tables is less predictable, ...
    (comp.object)
  • Re: object system...
    ... May I suggest just: "abstract record interface." ... separate classes and types in order to be able to do so. ... about a sane multiple dispatch instead of the mess. ... dispatch and vtables are used as these are the highest-performance options ...
    (comp.object)
  • Re: Separate Compilation in Programming Languages
    ... within one package body. ... all, separate or otherwise. ... OK, so you like having textually separate spec and body, ... Clients of an interface do not depend ...
    (comp.lang.ada)
  • Re: Separate Compilation in Programming Languages
    ... within one package body. ... all, separate or otherwise. ... OK, so you like having textually separate spec and body, ... Clients of an interface do not depend ...
    (comp.lang.ada)
  • Re: object system...
    ... (due to a side effect of how the interface mechanism is implemented, ... separate classes and types in order to be able to do so. ... is more of a library feature than a central part of the language it is being ... about a sane multiple dispatch instead of the mess. ...
    (comp.object)