Re: object system...

On Fri, 9 Jan 2009 00:01:09 +1000, cr88192 wrote:

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

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.

not exactly...

the new version keeps the same identity as the originan, and non-structural
state (such as static variables and overloaded methods) is shared between
the old and new versions...

= mutating objects. A bad idea, IMO.

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?

there are reasons for needing to keep class identity.

None in my eyes. Class identifies itself and the types in it.

consider a VM, say, the Java VM, has certain classes, say,
'java.lang.String', which need to exist prior to actually loading the class
file in which the class is defined.

so, early on the VM, a simple fake version of the class is implemented, and
once the actual version is loaded, it patches over the original. Now,
suddendly, all of the old instances become fully upgraded to their new
standing as an actual class with actual methods...

which potentially breaks all contracts. The stuff need to be recompiled,
end of story.

so, versioning is used such that the different layouts can coexist, while
still sharing everything else (class identity, slot and method handles,
...). externally, it doesn't look like much of anything has changed...

It is not IMO the way to do such thing. A proper way could be to make types
first class citizen. Then you would have type values and objects (and meta
types of). These objects would have states = versions in your terminology.
Anyway I doubt that types can be versioned independently. I guess that this
stuff must apply to larger entities like compilation units (packages etc),
rather individual types.

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.

not sure why this would be...

In a typed system you can separate implementation from the interface
(contracts). So long the contracts are stable, implementations can vary.

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

well, at this level, the class is bound physically to the layout.
changing the object class thus involves also a change in structure, and very
likely, a change in object identity.

the result then is not the old object with a new type, but a new object with
some of the old state...

Yes.

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?

dynamic delegation, ability to use an object the same as a dictionary absent
needing some separate kind of collection object, ability to dynamically add
slots and methods to an object, ...

These are means, but what is the goal?

also, it has the ability to implement a language like JavaScript without
introducing a semantic barrier (which is what would happen if implementing
these features on top of a C/I system, or as a separate object system).

I am not sure that languages like JavaScript should be implemented.
Actually, I am sure they better should not.... (:-))

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

it is called cloning in Prototype-OO terminology...

I prefer the old term.

but, this may be because there is a difference in the notion as to what is
an object (in P-OO, an object is never considered to be a value type, which
is what is required for assignment to be considered a means of duplicating
an object).

That's because they fail to separate types and classes. In a language where
they are separated you can copy a polymorphic object using assignment,
(because there is a distinct type for).

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.

I have not specified a language-level manifestation of all this, however,
were I to do so, it would probably be via special keywords...

That's the most interesting part, because an implementation is trivial.
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.

C++ does not have interfaces, so I don't see the problem...

C++ does not need interfaces because it has abstract types, which is a more
general concept than interface. The problem is in inconsistency and
inefficiency.

then again, in C++, MI is often used to similar effect as having
interfaces...

The inverse. Interface is a poor-man's MI.

however, interfaces do avoid some of the complexities of MI.

Huh, interfaces have all [alleged] problems of MI.

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.

errm, these issues are usually intrinsic.

user defined types are tpically slower, if anything, because they are not
natively implemented on the processor.

So are the predefined types of higher-level language. I don't count broken
assembler named C.

so, for example, 128 bit integers will be slower than 32 bit integers, and
within reason, this much is unlikely to change...

No, they are as slow as your best possible implementation based on 32-bit
instructions available. This is my requirement to the type system. I don't
require to rewire the CPU.

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.

well, otherwise I need to resort to other means to accomplish the same
tasks...

hash tables are a good and generally reliable mechanism IME, and are much
preferable to other options (such as linear or binary searches, ...).

My point is that I prefer linear search at compile time to a hash table at
run-time.

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)

but, it is rare enough to be safely ignored (and my initial hash tables are
fairly large...). more so, usually rehashing is a fairly quick operation
(not something you would want running all the time, but not really expensive
enough to be that much worth worrying about, given its relative rarity...).

This is still unbound. Technically you are talking about the mean 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 ... C/I is also unable to effectively facilitate some non-C/I languages, ... Performance of hash tables is less predictable, ...
    (comp.object)
  • Re: Change in C
    ... lists, hash tables, or similar. ... I don't think this is a problem to be solved at the language ... should just define a common interface, ...
    (comp.lang.c)
  • Re: object system...
    ... conflict with the actual sun and stars (so, ... Interface too can have some properties defined in terms of third types ... not the language or its target. ... If you ignore overflow exceptions, then necessary, the semantics becomes ...
    (comp.object)
  • Re: Great SWT Program
    ... not sure what the user interface of 2057 will be like, ... GUIs initially seemed to me. ... The clipboard will probably see big changes; ... difficult to program than in some other language. ...
    (comp.lang.java.programmer)
  • Re: Forth and Unix -- history
    ... Forth, as a language, gives you all the building blocks. ... So does FORTRAN, so does C, so does PERL, so does Python. ... to interface to some free library written in whatever language. ...
    (comp.lang.forth)
Quantcast