Re: A suggestion
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> wrote:
On 13 jan, 20:28, "Paul" <pchris...@yahoo.co.uk> wrote:
An object is the concept of a data structure which consists of
member data
and member functions. This is as much a fact as the fact that t=
he
sky is
blue.
No it is not, except in vulgarisation magazines. A more precise
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 language=
,
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 that
"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 look u=
p
the type of the node); that is the class.
No there are no classes in prototype based languages like Javascript,
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 hear
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, you
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 ful=
l
freedom to change their data model and behavior during their lifeti=
me
(and may do same to other objects that they know of).
In theory, but in practice, if it they change their interface, they
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, my
only point is that this feature is mainly useful at the development
stage, not at runtime (where a static typing language can then achiev=
e
the same).
I did not want to imply that more flexible is always superior or that 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 is
ultimately the programer that does. And the programmer does so by
having a blueprint of the object's capacity which I call (or I pretend
that they are) the class of the object.
The objects of
Javascript are not forced to stay in prototype where they started i=
n
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 clas=
s
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 inheritance
as OOP concept these days then he mentions delegation as alternative.
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 the
purpose of a feature.
......................................
No people do agree, its just this newsgroup that do not agree with the
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.
--
Michael