oop design

J

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
 
R

RobG

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 >
 
J

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

I don't see RobG answer...
 
R

RobG

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.


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 >
 
J

josh

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
thanks
 
R

RobG

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/c...pt+polymorphism&rnum=1&hl=en#326a67d74e2f5ea0
 
B

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-language> with it.
</OP>

My 2 cents...
 
T

Thomas M. Farrelly

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.
 
T

Thomas 'PointedEars' Lahn

(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
 
T

Thomas M. Farrelly

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.
Only because you don't understand it.

Please explain.
 
T

Thomas 'PointedEars' Lahn

Thomas said:
Example please.

From
http://developer.mozilla.org/en/doc...ting_New_Objects:Defining_Getters_and_Setters
(slightly adapted)

var d = Date.prototype;
d.__defineGetter__("year", function() { return this.getFullYear(); });
d.__defineSetter__("year", function(y) { this.setFullYear(y); });

var now = new Date();
window.alert(now.year); // 2007

now.year = 2001;
window.alert(now); // "current" date and time, but in 2001

WFM in Firefox 2.0.0.6.
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.
Etc. is such as compare, iterators, etc.

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

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).

Instead of comparing two values, one would use an array with two elements,
and sort that. If the first element of the sorted array equals the first
element of the unsorted array, then the first element is smaller (or larger)
than the second according to the used definition of order.

An example, with apologies to Lewis Carroll:

function Animal(iDanger)
{
this.danger = iDanger || 0;
}

Animal.prototype = {
constructor: Animal,

comparator: function(a, b)
{
if (a.danger < b.danger)
{
return -1;
}
else if (a.danger > b.danger)
{
return 1;
}
else
{
return 0;
}
}
};

var
snark = new Animal(-2),
boojum = new Animal(42),
animals = [boojum, snark];

animals.sort(snark.comparator);
if (animals[0] === snark)
{
window.alert("Snarks less wicked than Boojums might be"
+ "\n\tBut the Snark *was* a Boojum, you see.");
}

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.

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

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

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

Apparently you don't understand that iterating also over inherited
enumerable properties may be wanted. Nevertheless, it is quite easy
to ignore inherited properties when iterating.

for (var p in o)
{
if (o.hasOwnProperty(p))
{
// ...
}
}

and the like.


PointedEars
 
T

Thomas M. Farrelly


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
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.
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/New_in_JavaScript_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?
 
T

Thomas M. Farrelly


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
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.
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/New_in_JavaScript_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?
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top