Re: object system...

On Thu, 8 Jan 2009 20:35:22 +1000, cr88192 wrote:

"Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx> wrote in message
news:1iezboh1oejdf.x4om15uvsv7j.dlg@xxxxxxxxxxxxx
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?

yes. no.

the object system can access slots/members/fields directly from interfaces
as if they were normal instance slots...

crap, there are a lot of possible words for this simple idea:
slot;
field;
member;
variable;
...

May I suggest just: "abstract record interface." You have a type with the
operation ".". The operation can be implemented by the user. That's it.

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.

actually, more like, the object system does not bother to check that it does
so, and so everything that is not prevented (or will cause something to
break if done), is, by implication, allowed...

= untyped

so, it is a tradeoff:
as far as actual coding practice goes, doing something like this is rather
ugly; but as far as using it for the implementation of other languages, or for
using classes and interfaces outside of what they are normally used for,
these kinds of things can be rather useful...

I don't think so. It is a question if there is need to be a layer between
the hardware (untyped) and the higher-level programming language (typed). I
don't feel it necessary.

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.

an example of a situation in which the layout of a class would be modified
would be, for example, loading a new version of the class from a file, or
rebuilding an existing module.

New version of a class is another class. But you are already untyped, so
who cares.

say, the user has been working on a piece of code, and then their changes
have been committed, and these changes happen to include revising the layout
(such as by adding new slots or methods, ...).

.... removing slots, methods etc. Why old instances should work with new
implementations of new class?

The problem exists only because you go untyped. If your system where typed,
there would be no problem, because competing implementations of the same
interface could coexist.

attempting to make use of newer slots or similar may cause the object itself
to be re-packaged using the new layout (and, thus, brought up to date with
its class).

In a typed system old object would substitutable in the methods of its
subtype without further actions. Changing representation, if necessary
would happen transparently upon type conversions (forward and backward).

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

What for?

Prototype OO has some capabilities that Class/Instance OO does not...
C/I is also unable to effectively facilitate some non-C/I languages, such as
JS, ...

Example?

(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?

a clone of the object has the same type and state as the original, but a
separate object identity.

That is called assignment. x := y; BTW, not all types should have
assignment.

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.

I am not sure I know what you mean.

How to express in the language a wish to delegate, A of X to B of Y.

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.

multiple dispatch could be built on top of the system, however, single
dispatch and vtables are used as these are the highest-performance options
(handling multiple dispatch dynamically can be expensive...).

No, MD cannot be implemented on top of SD. Consequently vtable cannot serve
as a dispatching table of a MD method. vtable implements mapping type tag
-> method. In MD you have a Cartesian product of type tags of the
arguments, i.e. tuple -> method.

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

I am not sure I see the reason for this view.

Because it is inconsistent and extremely inefficient to mix them. An
example is C++, which re-dispatches all the time and keeps type tags in all
objects.

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.

my whole object system is an implementation issue, but I was describing some
of the impacts of this implementation...

Impacts on the design? That looks like a cart before the horse.

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.

not sure I follow.

Static analysis is based on the information provided by the user. More
declarative information you provide better analysis becomes possible.

In particular, static analysis of dispatch target becomes possible if it is
known whether the object is polymorphic or not. If these are of two
different types, e.g. class (polymorphic) and specific type
(non-polymorphic), then you can always statically decide on dispatch.

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.

if you mean built-in value types, yes, I have these...

No.

actually, given how everything exists, they are essentially unavoidable
anyways...

I wish same performance for all kind of types. It is unacceptable when
user-defined types inflict some performance loss. There is something
conceptually wrong with the types system then.

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.

actually, the whole system exists at runtime, because the entire framework
makes heavy use of dynamic compilation and JIT for everything...

Is this existence required? Compare, it is required presence of the
programmer, while the program is running... You cannot store the programmer
on the flash, it has to be payed, feed, needs some time to sleep.

but, anyways, the performance of the hash-tables is strictly bound:
if any lookup takes more than a certain number of steps, then the whole
table is expanded and all of the items are re-hashed...

= unbound (re-hashing requires time, lot of time)

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

Relevant Pages

  • Re: "Must instantiate controlled types at library level." Why?
    ... :>: dispatch table. ... When you write in a generic interface something like "type X is ", ... This requires either String or Wide_STring, ... I did say Eiffel not because it has MI. ...
    (comp.lang.ada)
  • Re: "Must instantiate controlled types at library level." Why?
    ... >: dispatch table. ... >With fallback entries, so you don't have to provide entries for ... An index type interface is more than just something ordered. ... You will have this for free with multiple inheritance. ...
    (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)
  • Re: object system...
    ... same interface will work on a class regardless of whether or not said class ... separate classes and types in order to be able to do so. ... It is not clear what features you mean. ... What I expect from a good system is zero performance hit when no dispatch ...
    (comp.object)
  • Re: Office Automation using MFC
    ... Is this a Windows CE question? ... > also returns a pointer to the Unknown Interface. ... > pointer to Dispatch Interface get a pointer to the Required Interface. ...
    (microsoft.public.windowsce.app.development)