Re: A taxonomy of types

On 2009-02-04, Stefan Ram <ram@xxxxxxxxxxxxxxxxxx> wrote:
Marco van de Voort <marcov@xxxxxxxx> writes:
Specify an object as what it should do, like:
- provide a container that combines both code (methods/actions) and data (fields)

So, they do not need to have a type.

This might make it difficult to obtain the meaning of the
methods at run time. At run time, one just has something
like a »vtable«, that is, an array of pointers to methods.
But one also needs to know, what these methods are supposed
to do (which interface/API they implement). A run-time type
would supply this.

It is possible in some OO languages to add methods to objects at runtime.
Method calling goes via sending messages with string method names.

Not optimal, but the definition has to be broad enough to include this,
otherwise we could simply suffice with "looks like Java".

- have a way to late bind. (and in statically typed objects, this means
inheritance)

(I do not see why inheritance is required here.)

It is not. It is a common way to achieve it. The more static the object
model typing is, the more likely you'll find it.

My explanation tried to make a difference between
»object-oriented programming« and an
»object-oriented programming language«.

I assume that one can do »object-oriented programming«
without an »object-oriented programming language«, for example,
in assembler. It begins in the moment, a subroutine accepts
an address to a memory buffer as an argument and the layout/structure/
encoding of this memory buffer is determined only as late as run time.

Is this really object oriented programming? (iow conceptual OO), or simply
imitating _a_ implementation of a "oo language" in assembler?

IMHO it is the latter, not the first. Yes, you can find techniques in that
assembler that remind one of code generated by a OO language with a static
inheritance model. But you don't know if it was done in OO spirit, or just
copy-cat.

In this case, there does not have to be direct late-binding support
in the programming language used.

One could argue the indirect assembler call is just that. But there you are
already blurring the border between implementation and definition again.

An object-oriented programming /language/ ads the management of
explicit messages/verbs/polymorphism at the source-code level to this.

"has language constructs supporting OOP". No reasons to get specific. Leave
the possible implementation/"view on how to do it" out of the definition,
and then give a typical (but not binding) example.

- have an identity operator. (which can be as dumb as pointer comparison)

(This is not that essential from my point of view.

I do not know, what an »identity operator« is, but I assume
that in Java, it would be »==« for references. Which
problem in the application domain can not be solved anymore,
when »==« for references is being dropped from the language?)

Well, the most used OO construct I think. Containers of objects. It requires
an identity operation.

- information hiding

Information is sufficiently hidden in the moment the programmer
only calls verbs of an object, but never accesses any of its
fields directly, unless he is just implementing a method for
objects of this type. Possibly this already is implied within
the basic concepts of object-oriented programming, so that it
needs no special mention. However, there are also other »paradigms«
that have information hiding, namely, »programming with abstract
data types«.

Point is, why is it _required_ for OO?

but it usually hides the type
information of objects and automatically assigns operations
specified for a type to each object.
Operations ? assignment? type info? Huh?

If one declares that an object »o« is of type »T«, and if type
»T« has an operation »f()«, then one can call »o.f()«.

Again, implementation details of _one_ particular view what objects should
look like. (e.g. even a fairly mainstream one as objective C has different
syntax and implementation).

Such details don't belong in a definition.

Two different methods with the same name might not have any relation at all.

This is true. For brevity's sake, I have omitted some
explanation on this.

Better scrap such specifics from a definition entirely. Keep it abstract,
and then treat a few languages (perferably from totally different groups)
and show how they implement these.

Keep it clear what is definition and what is implementation.

In fact (in the case of Java and
ignoring inheritance by »extends«), two different methods
with the same signature /do/ have the relation used /if/
they belong to classes A and B, so that A (directly or
indirectly) implements an interface IA whose declaration
directly contains this signature and B implements
(directly or indirectly) an interface IB whose declaration
directly contains this signature and if IA is IB.

So, inheritance via a different mechanims (interfaces), but still
inheritance. instead of the main VMT, you use the interface VMT. Not
any different from the "extends" case.

.

Relevant Pages

  • Re: Forth Frustrations
    ... I was working on an interface to my new window system in Ficl. ... I found it extremely frustrating to juggle around data on the stack, such as 2 RGBA color components when building a gradient. ... I've been accused of programming C in Forth, as if that's somehow terrible, but I digress... ... I was thinking that indexed keyed arrays might be an approach, or a completely different language. ...
    (comp.lang.forth)
  • Re: Question on abstract classes versus interfaces
    ... inheritance is not at all ... "interface A extends B"). ... In a language with no form of inheritance or delegation, ... layered over Java -- one with a different approach to OO in general. ...
    (comp.lang.java.programmer)
  • Re: Announce: Alpha release of BDB-BASIC
    ... those early BASICs, and are still most comfortable with them. ... language will be the most used to program microcomputers five years ... But as soon as you remove them you make the interface more ... programming language that's as easy to use as RPL (The programming ...
    (comp.lang.basic.misc)
  • Re: Programming Languages / IDEs
    ... I am not a professional by any means the Language I am most familiar ... How did you learn your programming skills? ... IMHO - an IDE does not really add that much. ... prototype interface in less time than the folks using visual studio on MS. ...
    (alt.linux)
  • Re: learning X programming
    ... X Toolkit Intrinsics -- C Language Interface ... how to get started with X programming under Linux would also be welcome. ... I have written X applications in Gtk, and when time permits, are exploring the X protocol by programming in Xlib only, using none of the higher level toolkits. ...
    (comp.os.linux.misc)