Re: object system...

On Sun, 11 Jan 2009 16:11:35 +1000, cr88192 wrote:

"Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx> wrote in message
news:749vn6hmsyca$.7n12zq0r7svb.dlg@xxxxxxxxxxxxx

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

Yep, spaghetti in short. This is like gotos eliminate any need in
if-then-else. The problem is that this is an extremely low-level stuff. If
you don't have types, you are unable to judge about sets of objects in
terms of their commonality. That is huge jump backwards into prehistoric
times of computing...

[... consequences of going untyped ...]

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

Yes, but the problem is to formalize the object environment in some way.
And what are the items in the environment? Other objects! What about the
environments of those. How these environments interact? Looks like a mess.

OO was introduced to sort out this mess by placing the volatile stuff
(states) into a thing called object. Either Kay wish to make
object-oriented into environment-oriented where "environment" is another
word for "object", or else, is it what?

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

Yes I see. This is what I certainly do not want to have = object of same
type implementing different interfaces! That looks like schizophrenia.

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

OK, that is the flawed model of C++ templates: let's take a type A and if
it *occasionally* implements B, we will use it as if it were B! Like if
there were "+" visible in the scope then it should be a number.

This is a non-starter to me, because it is either untyped (then it makes no
sense to talk about classes, interfaces, types), or else it is structural
types matching, which is incomputable with user-defined types (and is
incompatible with information hiding principle and other software design
practices). Which brings you to the square 1 = untyped.

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

No, unfortunately Ada cannot this because it also "merges" interfaces as
Java does. The example represents a use case which cannot be handled by
Java-like interfaces. Each element on the figure is in three doubly-linked
lists. If doubly-liked list would be an interface, the element's interface
would have to inherit it three times keeping all three separate. That in
turn would cause a name clash. [My solution is irrelevant here, because it
is not interface/inheritance based.]

To summarize:

interface = abstract type - implementations
abstract type = type - instances

If you have abstract type, you do not need interfaces, they already do all
what you need (provided MI).

The limitation not to have implementations (characterizing interfaces) is
just silly. It does not save you from the conflicts upon composition of
interfaces. There are two competing models of composition:

1. Idempotent: A + A = A
2. Additive: A + A /= A

*Both* models have their use cases. Both models require certain actions to
undertake upon composition of same interfaces independently on whether
implementations are present or not.

[Widespread cited commonplace popcorn about MI is largely rubbish.]

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.

Nope, that is C stance. The idea of a higher-level language is to abstract
the machine, not to expose it.

When you expose machine types, you cannot describe their semantics in a
machine-independent way, obviously.

That gives you no advantages, whatsoever. If modular 2**32 number fits the
machine register, the compiler would use that far better than me. It is
merely an optimization issue.

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

Yes, and the language problem is to encircle and insulate this dynamics.
The notion of class (dynamic polymorphism) is such a way.

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

Run-time support is a derivate of the language. It is a question what
belongs there. In my view it must be minimal. The dynamic stuff should be
possible to get at the language level as a set of libraries.

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

Relevant Pages

  • Re: High performance alternative to MI of virtual bases
    ... > implementations of interfaces. ... Heavy use of MI is abuse for the same reasons that simple inheritance is ... Inheritance -- multiple or otherwise -- is meant ... use of the core standard C++ language... ...
    (comp.lang.cpp)
  • Re: Static vs Dynamic
    ... > When you use reflection like this, it tells me that the base language ... Reflection as a base API distinguishes Java from its C++ ... interfaces are great for stabalizing types if you need to. ... Dog dog = new Dog; ...
    (comp.lang.lisp)
  • Re: Interfaces.
    ... modern language because they provide a way of separating the ... First of all, being a newbie, let me welcome you to python. ... Pythons dealings with interfaces are no exception. ... Java code that has successfully passed all the compile-time semantic ...
    (comp.lang.python)
  • Re: Name that language (if it exists), or comment on ideas for language.
    ... No implementation inheritance, only interfaces and delegation (with ... Language level support for resource scoping. ...
    (comp.object)
  • Re: No Equals on interfaces
    ... > for interfaces which is definitely not true and thus misleading. ... >> that's just language partisanship, it makes me think that the designers ... > reference to an object or a null reference, ... I don't think someVar is an ISomeInterface, ...
    (microsoft.public.dotnet.languages.vb)
Quantcast