oop design

[josh]

Hi,
I read a lot on how to make in Javascript programs in a OOP way. After
I download
many third-party library (like YUI, prototype ecc.) and I have seen
that almost
all the function (class) are designed like literal object notation and
not in a normal
way like I learned ... now I'm confusing
on how to design my classes... I came to a Java/C++ experience ...

It seems that with object literal notation we cannot make all the OOP
constructs
that we can make with normal Javacript class creation constructs... so
why is it so largely used?

Thanks

[RobG]

On Sep 10, 7:45 pm, josh <[e-mail]:

Hi,
I read a lot on how to make in Javascript programs in a OOP way. After
I download
many third-party library (like YUI, prototype ecc.) and I have seen
that almost
all the function (class) are designed like literal object notation and
not in a normal
way like I learned ... now I'm confusing
on how to design my classes... I came to a Java/C++ experience ...

It seems that with object literal notation we cannot make all the OOP
constructs
that we can make with normal Javacript class creation constructs... so
why is it so largely used?

This may help, particularly the last bit about Object-Oriented:

<URL: http://www.crockford.com/javascript/javascript.html >

--
Rob

[josh]

On 10 Set, 11:45, josh <[e-mail]:

Hi,
I read a lot on how to make in Javascript programs in a OOP way. After
I download
many third-party library (like YUI, prototype ecc.) and I have seen
that almost
all the function (class) are designed like literal object notation and
not in a normal
way like I learned ... now I'm confusing
on how to design my classes... I came to a Java/C++ experience ...

It seems that with object literal notation we cannot make all the OOP
constructs
that we can make with normal Javacript class creation constructs... so
why is it so largely used?

Thanks

I don't see RobG answer...

[RobG]

On Sep 11, 4:54 pm, josh <[e-mail]:

On 10 Set, 11:45, josh <[e-mail]:

Hi,
I read a lot on how to make in Javascript programs in a OOP way. After
I download
many third-party library (like YUI, prototype ecc.) and I have seen
that almost
all the function (class) are designed like literal object notation and
not in a normal
way like I learned ... now I'm confusing
on how to design my classes... I came to a Java/C++ experience ...

Javascript doesn't have classes, it has objects and a form of
inheritance via the prototype chain. It is explained in the link I
provided.

It seems that with object literal notation we cannot make all the OOP
constructs
that we can make with normal Javacript class creation constructs... so
why is it so largely used?

Because it is an efficient way to make objects. There are no classes
in javascript, though some libraries try to make things like there are
because their authors think that it's simpler to pretend javascript is
OO rather than trying to understand javascript.

e.g. Prototype.js has:

var Class = {
create: function() {
return function() {
this.initialize.apply(this, arguments);
}
}
}

which (surprise surprise) is just an object literal with one method.

The link I provided includes other links to ways to make javascript
emulate some of the attributes of classes.

I don't see RobG answer...

Do you mean don't see as in don't get it, or don't see literally, as
in can't see it at all. Here is the link again:

<URL: http://www.crockford.com/javascript/javascript.html >

[josh]

On 11 Set, 11:21, RobG <[e-mail]:

Because it is an efficient way to make objects. There are no classes
in javascript, though some libraries try to make things like there are
because their authors think that it's simpler to pretend javascript is
OO rather than trying to understand javascript.

e.g. Prototype.js has:

var Class = {
create: function() {
return function() {
this.initialize.apply(this, arguments);
}
}
}

which (surprise surprise) is just an object literal with one method.

so do you think that in a complex program when we can use
incapsulation,
inheritance and polymorfism is better not to use Javascript like a
class way?
and so how we can to abstract these concepts if we wanted to do?

Do you mean don't see as in don't get it, or don't see literally, as
in can't see it at all. Here is the link again:

oh I didn't see it as I didn't get it

<URL:http://www.crockford.com/javascript/javascript.html>

thanks

[RobG]

On Sep 11, 7:48 pm, josh <[e-mail]:

On 11 Set, 11:21, RobG <[e-mail]:

Because it is an efficient way to make objects. There are no classes
in javascript, though some libraries try to make things like there are
because their authors think that it's simpler to pretend javascript is
OO rather than trying to understand javascript.

e.g. Prototype.js has:

var Class = {
create: function() {
return function() {
this.initialize.apply(this, arguments);
}
}
}

which (surprise surprise) is just an object literal with one method.

so do you think that in a complex program when we can use
incapsulation,
inheritance and polymorfism is better not to use Javascript like a
class way?

OO is a design philosophy, all those concepts can be implemented in
javascript using objects - Douglas Crockford's article shows how to
implement some of them, like private and privileged members. If you
watch his video series, you'll get clues about how to implement other
OO concepts.

But OO isn't the best way to do everything, in the same way that a
procedural design isn't the best way for everything. I think part of
the magic of javascript is that it easily goes between the two.

and so how we can to abstract these concepts if we wanted to do?

Search the archives for posts, e.g.:

<URL:
http://groups.google.com.au/group/co...6a67d74e2f5ea0

>

--
Rob

[Bruno Desthuilliers]

RobG a écrit :
(snip)

>
OO is a design philosophy, all those concepts can be implemented in
javascript using objects - Douglas Crockford's article shows how to
implement some of them, like private and privileged members. If you
watch his video series, you'll get clues about how to implement other
OO concepts.

And in a previous post:

There are no classes
in javascript, though some libraries try to make things like there are
because their authors think that it's simpler to pretend javascript is
OO rather than trying to understand javascript.

(hope I'm not starting a flame-war here... If so, please just ignore
this post)

I may misunderstand you, but it seems you're not considering javascript
as an OOPL because it's not class-based - which I find a bit surprising.
AFAIK, OO stands for "*object* oriented", not "class oriented", and
there's just *no* notion of 'class' in the base OO concepts (ie : 1/ an
object is defined by an id, a state and a behaviour, 2/ an OO program is
made of objects communicating thru messages). IOW, the fact that most
mainstream OOPLs are class-based doesn't make the prototype-based
approach less OO.

As a side note, since javascript functions are themselves objects (and
FWIW, when defined at the 'top-level', attributes of the 'global' object
- usually the browser's 'window' object), using functions in
javascript is not necessarily doing procedural programming (as a matter
of fact, moderns javascript frameworks are more and more on the
functional programming side).
<OP>
Now there's at least a couple points where I totally agree with RobG :
OO is not the one-size-fits-all solution, and it's better to understand
the language you're using instead of trying to write
<whatever-other-languagewith it.
</OP>

My 2 cents...

[Thomas M. Farrelly]

On Tue, 11 Sep 2007 15:34:09 +0200, Bruno Desthuilliers wrote:

RobG a écrit :
(snip)

I find the lack of multiple inheritance and the inability to overload
get, set, assign, etc. problematic. And then there is the iterating over
properties of the entire prototype chain which I consider as strange
feature.

[Thomas 'PointedEars' Lahn]

Thomas M. Farrelly wrote:

On Tue, 11 Sep 2007 15:34:09 +0200, Bruno Desthuilliers wrote:

>RobG a écrit :
(snip)

(sic!)

What a very useful quote. NOT.

I find the lack of multiple inheritance

Multiple inheritance is possible with ECMAScript implementations.

and the inability to overload get, set, assign, etc. problematic.

JavaScript provides getters and setters. Other ECMAScript implementations
do not. What would `assign' and `etc.' be?

And then there is the iterating over properties of the entire prototype
chain which I consider as strange feature.

Only because you don't understand it.
PointedEars
--
"Use any version of Microsoft Frontpage to create your site. (This won't
prevent people from viewing your source, but no one will want to steal it.)"
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>

[Thomas M. Farrelly]

On Thu, 13 Sep 2007 09:43:58 +0200, Thomas 'PointedEars' Lahn wrote:

JavaScript provides getters and setters. Other ECMAScript implementations
do not. What would `assign' and `etc.' be?

Example please.

You know what an assignment is. Etc. is such as compare, iterators, etc.

>And then there is the iterating over properties of the entire prototype
chain which I consider as strange feature.

Only because you don't understand it.

Please explain.

[Thomas M. Farrelly]

On Fri, 14 Sep 2007 12:52:34 +0200, Thomas 'PointedEars' Lahn wrote:

From
http://developer.mozilla.org/en/docs...rs_and_Setters

This is good stuff. Was not aware of that. ( tin-tags is my first js and
clientside web project )

Is it also possible to "catch" all property accesses? If so, then one could
easily implement multiple inheritance by making the prototype object look
through a list of prototype objects for dispatch.

o.prototype = {
// this is the list of prototypes
prototypes : new Array(),
// seach for propertyName in prototypes
_get_ : function( propertyName ) { ... },
// set property locally, of course
_set_ : function( propertyName, value ) { ... }
}

so

o.prototype[ somePropertyName ]

would return a property from an object in the o.prototype.prototypes array
and not from o.prototype. The notion of getters and setters in python lets
you do this.

If this isn't possible to do quite like this, is there a different way to
avoid cut'n'paste inheritance. I imagine a horrifyingly bad hack to do this
:-P

>>What would `assign' and `etc.' be?

You know what an assignment is.

I know that, but I could not make anything of your statement that it would
not be possible to overload _"assign"_ as you already mentioned "set", which
is the same thing.

Maybe you should elaborate on such general statements in the first place.

For example you want

a = 1 ;

to be equivalent to

a.value = 1 ;

or

a.setValue( 1 ) ;

Guess this is mostly useful in statically typed languages, but it would be
nice to modify this behaviour in js, for example to preserve type or apply
data invariants and so forth. Using "a.value" with the overloading of
getters and setter does the trick though or you would write

a = AType( 1 ) ;

Which works too. Just a thought.

>Etc. is such as compare, iterators, etc.

That is a recursive statement, so not of much use.

Recursion is useful ;-)

>
User-defined comparators are possible using Array objects since JavaScript
1.1 (NN 3.0/NES 2.0, 1996-08 CE), JScript 2.0 (IE/MSHTML 3.0, 1996),
ECMA-262 (Edition 1, 1997-06).

This is quite bad.

The algorithm could be wrapped into a method that is provided the first and
the second value as arguments. It would then create the array consisting of
those two elements, look for a comparator method and call Array::sort()
passing the method reference if such a method exists, and so on. However, I
would like the possibility to overload the comparison operators directly
instead, of course.

Yes, that would be much better.

Iterators can be defined in JavaScript since version 1.7 (Firefox 2):

http://developer.mozilla.org/en/docs..._1.7#Iterators

However, it is not that hard to define and use them in earlier versions and
other implementations without that language feature.

It is unclear to me whether this allows for modifying the behavior of
for-in. Is it possible to set the iterator of Object to always do the
hasOwnProperty test for example?

[Thomas M. Farrelly]

On Fri, 14 Sep 2007 12:52:34 +0200, Thomas 'PointedEars' Lahn wrote:

From
http://developer.mozilla.org/en/docs...rs_and_Setters

This is good stuff. Was not aware of that. ( tin-tags is my first js and
clientside web project )

Is it also possible to "catch" all property accesses? If so, then one could
easily implement multiple inheritance by making the prototype object look
through a list of prototype objects for dispatch.

o.prototype = {
// this is the list of prototypes
prototypes : new Array(),
// seach for propertyName in prototypes
_get_ : function( propertyName ) { ... },
// set property locally, of course
_set_ : function( propertyName, value ) { ... }
}

so

o.prototype[ somePropertyName ]

would return a property from an object in the o.prototype.prototypes array
and not from o.prototype. The notion of getters and setters in python lets
you do this.

If this isn't possible to do quite like this, is there a different way to
avoid cut'n'paste inheritance. I imagine a horrifyingly bad hack to do this
:-P

>>What would `assign' and `etc.' be?

You know what an assignment is.

I know that, but I could not make anything of your statement that it would
not be possible to overload _"assign"_ as you already mentioned "set", which
is the same thing.

Maybe you should elaborate on such general statements in the first place.

For example you want

a = 1 ;

to be equivalent to

a.value = 1 ;

or

a.setValue( 1 ) ;

Guess this is mostly useful in statically typed languages, but it would be
nice to modify this behaviour in js, for example to preserve type or apply
data invariants and so forth. Using "a.value" with the overloading of
getters and setter does the trick though or you would write

a = AType( 1 ) ;

Which works too. Just a thought.

>Etc. is such as compare, iterators, etc.

That is a recursive statement, so not of much use.

Recursion is useful ;-)

>
User-defined comparators are possible using Array objects since JavaScript
1.1 (NN 3.0/NES 2.0, 1996-08 CE), JScript 2.0 (IE/MSHTML 3.0, 1996),
ECMA-262 (Edition 1, 1997-06).

This is quite bad.

The algorithm could be wrapped into a method that is provided the first and
the second value as arguments. It would then create the array consisting of
those two elements, look for a comparator method and call Array::sort()
passing the method reference if such a method exists, and so on. However, I
would like the possibility to overload the comparison operators directly
instead, of course.

Yes, that would be much better.

Iterators can be defined in JavaScript since version 1.7 (Firefox 2):

http://developer.mozilla.org/en/docs..._1.7#Iterators

However, it is not that hard to define and use them in earlier versions and
other implementations without that language feature.

It is unclear to me whether this allows for modifying the behavior of
for-in. Is it possible to set the iterator of Object to always do the
hasOwnProperty test for example?