Re: A suggestion
"Michael Doubez" <michael.doubez@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 the
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 up
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 full
freedom to change their data model and behavior during their lifetime
(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 achieve
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 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 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.