Re: A suggestion

From:

Michael Doubez <michael.doubez@free.fr>

Newsgroups:

alt.comp.lang.learn.c-c++,comp.lang.c++

Date:

Tue, 18 Jan 2011 00:43:27 -0800 (PST)

Message-ID:

<b6f9a347-de72-4b09-b6c1-1f490aefc761@fu15g2000vbb.googlegroups.com>

On 18 jan, 01:33, =D6=F6 Tiib <oot...@hot.ee> wrote:

On Jan 17, 11:06 am, Michael Doubez <michael.dou...@free.fr> wrote:

On 17 jan, 02:10, "Paul" <pchris...@yahoo.co.uk> wrote:

"Michael Doubez" <michael.dou...@free.fr> wrote in message

news:7681fb72-6ac5-41d4-8a33-3d4dc736ca25@f20g2000vbc.googlegroups.com=

....

On 16 jan, 17:28, Tiib <oot...@hot.ee> wrote:

On Jan 16, 12:50 am, Michael Doubez <michael.dou...@free.fr> wrote:

On 14 jan, 21:13, Tiib <oot...@hot.ee> wrote:

On Jan 14, 12:11 pm, Michael Doubez <michael.dou...@free.fr> wr=

ote:

On 13 jan, 20:28, "Paul" <pchris...@yahoo.co.uk> wrote:

An object is the concept of a data structure which consists=

member data
and member functions. This is as much a fact as the fact th=

at the

sky is
blue.

No it is not, except in vulgarisation magazines. A more preci=

definition is "an object is an instance of the data structure=

and

behaviour defined by the object's class". You cannot make
abstraction
of the class concept, otherwise, you don't have the model for=

the

object's state, methods and interaction; even if the class is=

not

expressed by the language (in some languages where functions =

are in

fact data members, like in javascript).

"A class" (like in class-based OO languages) makes no sense in
Javascript.

IIRC, in javascrpit OO works on the pattern

function MyClasse(parameter1, parameter2) {
this.attribute1 = parameter1;
this.attribute2 = parameter2;

this.method = function() {
alert("Attributs: " + this.attribute1 + ", " +
this.attribute2);
}

}

var obj = new MyClasse("value1", "value2");
obj.method();

The class does exists although, like in mainy dynamic typing lang=

uage,

it is not formalized at the language level.

There is prototype, you clone that prototype with new, not create
instances of class. You can add methods to prototype outside of tha=

"contructor" like "MyClasse.prototype.otherMethod = function()
{ return 42; }" and from there on the clones have it too.

When working on the DOM of a page, you still have to lookup the
members and the methods available at the nodes (in fact you do lo=

ok up

the type of the node); that is the class.

No there are no classes in prototype based languages like Javascrip=

Actionscript or Lua. Static classes are good for compiled languages
and allow simpler optimizations.

I think we should define class and its context otherwise we won't hea=

one another.
When I talk about class in the OOP context, I mean the abstract
characteristics shared by all object of the class.

And I did'nt speak about static class. But when you get an object, yo=

must know something of the object, even inspection can give you
meaning about the object only if you have some meta-knowledge (like
duck-typing in C++).

Class is other (less flexible) concept than that language
supports. Javascript's prototypes are not classes. Objects have=

full

freedom to change their data model and behavior during their li=

fetime

(and may do same to other objects that they know of).

In theory, but in practice, if it they change their interface, th=

become useless because you don't know what method you can call. I
won't start the dynamic typing vs static typing all over again, m=

only point is that this feature is mainly useful at the developme=

stage, not at runtime (where a static typing language can then ac=

hieve

the same).

I did not want to imply that more flexible is always superior or th=

at C

++ is not flexible enough. However ... like you see, some template
wizardry of C++ is used to achieve more dynamic types like
boost::variant or more dynamic functions like with boost::bind. So
there is a market for more run-time flexibility in C++ community.

My point here was to say that as soon as the program is finished in
the dynamic type language, you could rewrite it in static type
language. As an example, IIRC there is a ruby to C interpreter/
compiler.

In the facts, even if an object could mutate beyond recognition, you
don't do it because the program cannot deduce meaning by itself, it i=

ultimately the programer that does. And the programmer does so by
having a blueprint of the object's capacity which I call (or I preten=

that they are) the class of the object.

The objects of
Javascript are not forced to stay in prototype where they start=

ed in

and so they simply have no class.

They don't have to but, as I said, in practice you do.
As an example, in prototype.js you define classes (among other
things).

In fact, I don't see how you can speak about inheritance without =

class

and inheritance is (arguably) a base concept of OOP.

I don't think that it is mandatory concept. In Javascript there are
cloning of prototypes and delegation and reflection. Quite powerful
features if to think of it. Usually when someone talks of inheritan=

as OOP concept these days then he mentions delegation as alternativ=

From my point of view, inheritance is the fundamental concept of the
implementations: prototype, meta-object ... I think it depends on the
level you are talking. Prototype base language are defined as class-
less programming so I might be wrong.

Well, that's the curse of OOP, nobody agree on a definition and/or th=

purpose of a feature.

......................................

No people do agree, its just this newsgroup that do not agree with th=

geneal public.

Please, get a little more background on the subject before answering
such useless comment; this is very trollish.

As for continuing with =D6=F6 Tib

For prototype-based/class-based languages, "A theory of objects" by
Mart=EDn Abadi and Luca Cardelli note:
<quote>
The main insight of the object-based model is that class-based notions
need not be assumed, but instead can be emulated by more primitive
notions. Moreover, these more primitive notions can be combined in
more flexible ways than a strict class discipline.[....]
</quote>

This backs my claim that that you cannot do without class (as I
understand it) but my defintion must be broader than generally
accepted since it is clearly defined as a language without class.

Yes, perhaps you imagine classes differently than on common case.
Commonly a class is fixed template. A type that is sort of self-
contained and does not change for particular object. There are
inheritance hierarchies of classes to gain some flexibility with fixed
set of "reasonable" combinations. On most cases it is good enough.

The prototypes are more flexible than classes. Objects can gain and
change their abilities and attributes during their life-time. Objects
interfaces (and amount of available interfaces) may change
dynamically. That makes prototype-based objects more life-like. More
flexibility may make it more complex, but like your book say that
class-like behavior may be always emulated where it is good enough.

For simple example ... a door. It does not make sense to lock (or
unlock) it when it lacks locks. Either there is always an interface
that does not make sense for all doors or ... if it initially did not
have locks then you have to "destroy" the lockless door and
"construct" new one with lock to add a lock to door.

Ok. I stand corrected.

--
Michael