Re: object system...


"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;
....


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...

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...


it is much like a flat-tip screwdriver:
officially, the use of a flat-tip screwdriver is for the rare event that one
encounters flat-tip screws.
so, the result is that most tool sets come with a tool that is, by
definition, fairly useless most of the time...

but, unofficially, the practice of such a screwdriver can be extended to
include many other tasks:
as a wedge for driving things apart;
as a prying implement;
for physically removing gunk from a surface;
sometimes as a kind of chisel;
....

and, if effect, they are so often used for these kinds of tasks that they
become the new definition of the utility of the tool (even if these kinds of
uses are undocumented and regularly discouraged...).


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.

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, ...).

the user may think, "well, all I have done it added a few new fields and a
few new methods...", while failing to take into account that this will
require physically reorganizing the contents of both this class, any
subclasses, and potentially any instances of the class that exist.

the use of object versioning, however, allows the change to be less drastic.
for example, objects and subclasses can be left unchanged until at which
point these changes actually matter, and when these changes to take place,
they need not be disruptive (for example, creating a new instance of a given
class whose ancestor has been modified may cause this part of the
inheritence graph to be brought up to date, but without disrupting any prior
existing instances).

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).


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, ...


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

but, "type" is a rather complex issue in my system, where the object system
is more of a library feature than a central part of the language it is being
primarily used from (C), and there is another such system in place that can
also be called a typesyste, ..., but its standing is different in different
contexts.


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.


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...).


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 am not sure I see the reason for this view.


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...


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.


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...

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


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...

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...

of course, this is an unexpected and potentially significant delay, but it
can be compared to, for example, an unexpected quantum end, or the garbage
collector kicking on...


of course, I have my own interesting algos here, of which I have not found
any info about others using a similar approach to hashing (I make heavy use
of psuedo-random permutations, ...).

or such...


--
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: 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: "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...
    ... 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)