Re: object system...


"Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx> wrote in message
news:749vn6hmsyca$.7n12zq0r7svb.dlg@xxxxxxxxxxxxx
On Sat, 10 Jan 2009 00:17:06 +1000, cr88192 wrote:

"Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx> wrote in message
news:8me0gsbq64xn.yl21j2101cti.dlg@xxxxxxxxxxxxx
On Fri, 9 Jan 2009 17:13:29 +1000, cr88192 wrote:

"Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx> wrote in message
news:1i10n69z8xcdq$.16kkhaz0ituqy$.dlg@xxxxxxxxxxxxx
On Fri, 9 Jan 2009 00:01:09 +1000, cr88192 wrote:

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?

supporting certain kinds of programming languages and formalisms that
would
otherwise go unsupported...

Formalisms or sloppiness?

these styles of languages are designed this way intentionally...

[...]

so, Alan Kay is involved with all this, and he can be considered an
authority over what is OO, and so, P-OO is also a form of OO, although
granted it is different from C/I-OO.

Lieberman's stuff is all wrong to me. "Delegation between object" sounds
conceptually messy.


given what all else is said, this does not surprise me...

the way it all works is actually quite "elegant" in and of itself (since the
use of delegation and cloning can eliminate both the need for classes, and
also the need for inheritence).

but, as I see it, there are other problems:
I am not aware of any way in which a prototype system can be implemented
(and remain as a prototype system at runtime), while still delivering
performance anywhere near that which is possible with a class-instance
system;
prototype systems are also not statically provable, so one has to take it on
faith (and runtime checks) that it will all actually work.

so, I opted with a class instance system hacked over some to emulate a
prototype system, rather than a prototype system emulating a class/instance
system.

now, it is not like prototype systems require endlessly performing recursive
searches to locate slots, rather, one can make a big hash table, and use
this to locate most slots or methods in O(1) time.

the problem though is that looking up a value from a hash table is more
expensive than using a hard-coded offset, and also that prototype systems
tend to fill up the hash table fairly quickly (since each and every object
may try to have a spot for itself, and there may be lots of objects, so
often one will still end up searching for the slot...).

also, in a system like this, any change which could potentially cause a
lookup to give a wrong answer (such as adding a slot to an object, modifying
part of the delegation tree, ...) requires flushing the hash table, which
usually incurs a not-so-small performance hit.


meanwhile, for all this, a hybrid approach can deliver much better
performance, since the heavy use of hashing can be reduced to less common
cases (interfaces and dynamically added fields and methods), a class can
never re-assign its superclass (very simply, this is a change not allowed by
my system...).

so, at least when being used for (mostly) static / C/I tasks, my system
should deliver superior performance to a P-OO based system, and even for
P-OO, the performance should still be fairly decent...


As for Kay, this is a different case. He talks about transaction-oriented
approach to object updates. This is quite concrete and I agree that this
is
a very important issue. But I have some reservations:

1. This is not an alternative (it is rather a meta layer)

2. This cannot be reduced to just one object. I.e. it is not literally OO,
because it involves many objects. He introduces "world," but this is too
sloppy in my eyes. I would expect some *object* corresponding to the
"world."

In short a bit more meat is required to consider it seriously. Especially
because the theory of OO itself is quite shaky, while it [obviously]
should
serve as a basis for transactions.


yeah...

I guess the idea though is that usually one thinks much more in terms of an
"object world" or "object environment" than in terms of individual objects
in isolation...


but, anyways, I guess the basic idea is that C/I-OO and P-OO represent
different formalisms, but in any case, both are formalisms...

So far, I doubt it.


well, that or they are 2 versions of the same formalism (P-OO being the
"general" form, and C/I-OO being a specific and restricted subset).


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

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

it depends on how one looks at it, interfaces, as they exist in the JVM
and CLI, are a rather different concept than MI, with various strengths
and
weaknesses, ...

for example, there are things that can be done with one and not the
other, and also the reverse...

?

each one is not strictly a subset or superset of the other as far as
behavior goes, but rather both MI and interfaces would seem to represent
similar, but none the less different, constructs...

for example:
an interface does not "add" anything to an object, but instead requires
the
object to contain the methods in question;

Interface deals with the type, not an object of. As any base type it adds
nothing being a separate type from the result. Inheritance is an algebraic
operation that takes some arguments, like interface, and produces the
result, the type or interface.


we use interfaces against instances / objects, not against classes...

interface Bar {
....
}

class Foo implements Bar {
....
}


Bar obj = new Foo();

obj.method();
....

so, the interface is being used with an object, not with a class...

it just so happens that we can stuff any instance of any class implementing
an interface into a variable defined using that interface.


using MI will in effect create the methods, but an interface requires
they
already be there;

You consider mutating types. It is irrelevant whether the result overrides
and existing type or produces a new one. The operation of inheritance
remains exactly same.

It is like to argue that += is not an addition because it replaces the
result.


not really...

it is only a formality IMO that a class be declared as implementing an
interface, but given an interface need not actually change the class that
implements it (and, in fact, the class has to already have the methods in
question before it can implement an interface), it is conceptually different
IMO from inheritence, which by definition defines the structure of an
object, rather than giving a means of abstracting whatever is already
there...


interfaces don't introduce scoping conflicts

They certainly do.


not from what I read, unless the JVM and .NET framework have gotten
something horribly wrong in their designs...


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

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

not quite...

since an interface doesn't actually implement anything, there is no
real
need to worry about clashes or lookup order (since 2 methods which
match
will simply merge). as a result, one major class of problems that
exists
in MI (having to identify which of the superclasses a given method came
from, ...) simply dissapears.

Nope. Consider a doubly-linked list interface. Now if you derive a new
interface from it, you have the conflict in the case when the interface
is
inherited twice. The method Next does not merge when the same item
should
participate in two lists. For instance, a device port can be in the list
of ports and in the notification queue.

I don't follow your example...

could you write out an example of this issue (like in Java or C# or
similar?...).

Here is a picture of tripled doubly-linked web of nodes:

http://www.dmitry-kazakov.de/ada/components.htm#Generic_Doubly_Linked_Web

Each node participates in three lists. In terms of interfaces a node
inherits doubly-linked list interface three times and no merging happens.


I am not an expert on Ada, but I am not sure I am seeing any interfaces...
to me, as a guess, it looks more like MI is being used here?...


well, yes, in my compilers and such, 128 bit ints and similar are built
in types...

What about 100 bit? In a higher-level language you write:

type Number is range 1..100;

The compiler is responsible to choose an implementation. The idea of
built-in numeric types is all wrong.

100 bit would not be represented effectively, one can have either 64 or
128
bits, but not 100...

You have no alterative. The point is, the application dictates the
implementation, not reverse. If I need N bits number (properly speaking a
modular number of modulus 2**N), then I just say so in the language. The
compiler has to find the best possible way to provide me an implementation
of. The word "best" means: any other solution (including assembler) would
be less or equally efficient. This is a simple example, but the same
principle must apply to all types without exception.

Predefined types break this principle. They force me to use a type that is
not exactly one needed by the application. This opens a can of worms.


usually the typesystem provides a similar typeset to those which exist on
the CPU, and to do different would reduce performance.

as far as giving a specification and having the compiler pick something, or
the developer picking from a pre-existing list, I am not sure why it would
make much difference, only that providing a specification will take more
effort and the compiler will just pick one of the fixed-size types anyways,
and so it is more preferable just to keep on expanding the list of built-in
types as needed...


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

in my case, both compiletime and runtime are sort of fused together...

Yep, like the programmer is fused with the program etc. It is too late
to
ask why you need a WC on the Mars probe. The choice was made before.

?...

Just an example of that the process of "fusion" should stop somewhere. If
you start to fuse compile-time with run-time, you will probably end with a
programmer on board. Actually, the process must be reverse. All the things
possible to do before run-time must be accomplished then. This includes
such activity as programming, you better program before you execute (:-)),
and static analysis as well. So the word "dynamic" is always suspicious to
me. I don't want it "dynamic" unless otherwise is proved impossible.


a good portion of the time, these dynamic programming facilities are not
actually being used by the programmer directly, rather they are a tool to
allow the programmer to write code that writes more code to accomplish some
task.

the great problem is that, at compile time, niether the programmer nor the
code may know all of what may happen at runtime, and not all tasks are
possible purely through the use of plain logic code, so the result is that
one ends up with a good amount of dynamic facilities, such that the
programmer can write code (usually, statically), which causes the app to
begin writing its own code at runtime to accomplish the tasks with which it
is presented...

another major purpose is to make make other tasks either more convinient, or
more efficient (often spewing out a chunk of code specialized for a
particular task can deliver higher performance than the use of a general
purpose algorithm for the task).


so, as the app goes along, it may end up writing a good deal of its internal
structures at runtime, and having abilities that are generally lacking in
purely statically-compiled apps, such as the ability to "absorb" other
libraries and code into itself, ...

and, other code can be made to make use of the code for the first
self-writing code, and so the original capability is expanded further...


this may all actually save a good deal on what code actually has to be
written as well, since it takes a lot less code to get something done if the
app can made to write the code for doing so itself...


granted, all of this is stuff usually far more commonly associated with LISP
than C, but the framework is multi-language (and I am working on
"assimilating" other frameworks as well, such as the JVM and .NET, such that
I may gain a hopefully "non-linear" payoff in terms of capability...).

meanwhile, eventually it could help if it is able to make use of data at a
"higher level of abstraction" than that of code and conventional data
formats, for example, if English text could also be used as a data
representation, and certain emulations of human cognitive processes could be
used as programming constructs, ...


or such...


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


.

Relevant Pages

  • Re: Inheritance and Polymorhpism (getting back to the point)
    ... That means in dynamically typed languages there is simply an interface ... languages like Python, they inherit on purpose from a base class ... The SAX API defines four kinds of handlers: ...
    (comp.object)
  • 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: A taxonomy of types
    ... With this explanation OO (as seen in statically typed OO languages ... The static type defines the interface for the variables, ... objects (in the Seed7 philosophy really everything is an object), ... OCaml, which applies to lists of ints, lists of strings, etc.) and, say, ...
    (comp.lang.misc)
  • Re: Philosophy of Polymorphism (was: Meyer(s) gets it wrong)
    ... I am NOT talking to a driver - I am talking to an interface in the ... Thus, it is not a case of "instance variables", unless you consider the ... you have a single object (the dispatch printer) ... browser (and its programmer) have to make do with whatever server I ...
    (comp.programming)
  • Re: Interaction between subclass and UI
    ... dialog or control for each subclass. ... You create an interface that is used to construct related objects. ... my ILanguageGenerator heirarchy has three concrete objects: ... the user has a menu that shows the different languages that they can ...
    (comp.software.patterns)