Re: object system...

On Mon, 12 Jan 2009 11:49:12 +1000, cr88192 wrote:

for example, few are likely to doubt that a 'for' or 'while' loop is
preferable to an 'if-goto' construction, none the less, goto and labels are
the more general construct, and if-goto can be considered more as syntactic
sugar.

Yes, and the evolution of languages goes from more general to less
dangerous constructs. It is no problem to get it Turing complete, so
genericity was not an issue since the day one.

none the less, it is a lot easier to optimize code with loops or
if-then-else, than code written via gotos (optimizing if a given branch is
always true or false, unrolling loops, ...), however it is also the case
that nearly every compiler I am aware of converts over to the use of gotos
fairly early on (and I am not aware of any IL which uses high-level control
flow rather than labels and gotos/jumps...).

[...]

so, yes, although one can use prototype features, they should not, as the
additional overhead costs are high.

Also, in a typed system you do not need to store any specific type
information at run-time. The type tag is needed in only two cases:

1. The object is polymorphic and its specific type is unknown until
run-time

2. The representation of a non-polymorphic object is same as the
representation of a polymorphic object rooted in the specific type of the
former.

The case 2 is usually deployed by when objects are by-reference.

also, note that the memory overhead of storing a class is not exactly small
either (a class likely by far dwarfs the instance), but this is OK as the
number of classes is likely to be small vs the instances (in total, each
class is likely to take several KiB of memory...)

You do not need to store classes (except when first-class objects) at all.
Classes are truly static when there exist only non-polymorphic objects and
polymorphic objects. But you would need to store classes if you had classes
of classes, e.g. second order polymorphic objects.

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.

this is common practice though, and actually one of the major uses of
interfaces. well, that and allowing different classes to be used in the same
place (AKA: a poor man's duck typing...).

One does not need to be schizophrenic, it is no problem for an object to
have a type to be a member of many classes. The relationship is:

an object <--1:1--> the type <--1:n---> classes of

An object has exactly one type. Interfaces deal with types not objects. An
interface declares some set of operations defined on some set of values. It
is meaningless to apply this to an individual object. It is like to have 1
integer without 2. How + is supposed to work? Integer interface applies to
all integers.

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.

then why were you saying that interfaces do not merge?...

Because they do not. I need three different operations Next, when element
is in three lists.

in effect, they do merge, and this is why one can't implement the same
interface multiple times, because in effect this neither works, nor does it
make sense conceptually.

?

MI could probably do this, in the funky way MI tends to work, but tends to
disallow merging the inheritence graph (I had thought this tendency to
fragment was an implementation artifact, but apparently it has some use...).

Why MI should tend to disallow anything? In C++ we can find both cases 1
and 2 supported. Where is a problem?

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.

?...
then why don't we all go and use Haskell or Prolog?...

I don't see any connection. There might be problems with Haskell and
Prolog. Anyway it is not a language popularity contest. As we all know the
language of all times is Visual Basic...

I say, the purpose of a higher level language is to get more work done more
effectively, and if this is by hiding or exposing the machine is not
important, only that more work be done, that it be done faster, and that it
be done better...

It cannot be unimportant, because exposing machine prevents some vital
optimizations. For example, if you handle register allocation manually, you
prevent the compiler to do it for you. And with most of optimizations the
compiler will beat you by margin.

That is apart from the issues of code reuse, portability, safety,
maintainability etc.

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

doesn't matter when the machines in question implement more-or-less the same
semantics...

How do you define "more or less same semantics?" Computing is discrete, 1+1
is either 2 or else wrong. Does 15326+35221 overflow?

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.

maybe, but there is probably some reason that user-variable number types
went away.
COBOL gave us them, and a few languages since, however the common consensus
would seem to be that they don't offer enough advantage to be worth
including them...

Really? Sorry, but I am dealing with data acquisition and control. It is
damn important to me not to sent 10 E+37 km/h to the wind fan. The thingy
is hundreds of thousands dollars...

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.

a class can wrap stuff like this, but so can a plain API.

Really, how? If "plain API" reads "functions and procedures." Then what are
the types of the arguments and results? void *, I guess?

well, this is along with me now splitting my GC and typesystem+object system
into separate libraries...

Yes.

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

Relevant Pages

  • Re: object system...
    ... for example, my C compiler, for x86-64, emits mangled names. ... we use interfaces against instances / objects, ... Each node participates in three lists. ... Anyway it is not a language popularity contest. ...
    (comp.object)
  • 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)
Quantcast