Re: object system...

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.

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.

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.

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.

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.

interfaces don't introduce scoping conflicts

They certainly do.

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.

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.

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.

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

Quantcast