Prototype OO

Some time ago (2004) there were talks about prototype-based languages and
Prothon emerged.

Can someone tell me why class-based OO is better that Prototype based,
especially in scripting langage with dynamic types as Python is?


Here are some links:

http://c2.com/cgi/wiki?PrototypeBasedProgramming
http://developer.mozilla.org/en/doc...Based_Languages



--
UFO Occupation
www.totalizm.pl

On Wed, 19 Mar 2008 17:59:40 +0100, sam wrote:

> Can someone tell me why class-based OO is better that Prototype based,
> especially in scripting langage with dynamic types as Python is?

Is it better!?

Ciao,
Marc 'BlackJack' Rintsch

sam a écrit :
>
> Some time ago (2004) there were talks about prototype-based languages
> and Prothon emerged.
>
> Can someone tell me why class-based OO is better that Prototype based,

For which definition of "better" ?-)

> especially in scripting langage with dynamic types as Python is?
>
>
> Here are some links:
>
> http://c2.com/cgi/wiki?PrototypeBasedProgramming

Most of the arguments in favor of prototypes seems to come to, mainly:
1/ it lets you customize behaviour on a per-object base
2/ it removes the mental overhead of inheritance, classes etc

Point 1. is a non-problem in Python, since you can already add/replace
methods on a per-objec basis (ok, with a couple restrictions wrt/
__magic__ methods and such).

Point 2. is not (IMHO) such a problem in Python, where inheritance is
mainly an implementation detail (it's not needed for polymorphic
dispatch to work) and class hierarchy tend to be very flat, when they
even exist.

Mainly, Python's object system is actually quite close to javascript
here. That is, you get more or less the same flexibility. And a couple
of powerful features you don't have with javascript (like hooks in the
attribute lookup mechanism), too.

Bruno Desthuilliers napisa³(a):

> Most of the arguments in favor of prototypes seems to come to, mainly:
> 1/ it lets you customize behaviour on a per-object base
> 2/ it removes the mental overhead of inheritance, classes etc
>
> Point 1. is a non-problem in Python, since you can already add/replace
> methods on a per-objec basis (ok, with a couple restrictions wrt/
> __magic__ methods and such).
>
> Point 2. is not (IMHO) such a problem in Python, where inheritance is
> mainly an implementation detail (it's not needed for polymorphic
> dispatch to work) and class hierarchy tend to be very flat, when they
> even exist.
>
> Mainly, Python's object system is actually quite close to javascript
> here. That is, you get more or less the same flexibility. And a couple
> of powerful features you don't have with javascript (like hooks in the
> attribute lookup mechanism), too.

Thanks for precise opinion and spending your time.


I think that when you use statically typed language, than you have to define
classes, because compiler has to know what is allowed to do with instances o
f
that class.

But when you use dynamically typed language, then classes are redundant, bec
ause
object is looked at when it is referenced. Dynamically typed language needs 
only
objects hierarchy and you can add properties (methods, values) to that objec
t
during program execution.

In dynamically typed language when you create object A that is inherited fro
m
another object B, than object A knows that B is his predecessor. So when you
reference A.prop, then prop is looked in A first, then in B, then in
predecessors of B, and so on.

Having object A you can access its predecessor B. When you have access to ob
ject
B, then you can add properties to it and these properties could be accessed 
by
all other objects inherited from B.

You can do all these things in Python. But why it uses classes?

So you can say: "CLASS BASED PROGRAMMING" == "STATICALY TYPED LANGUAGE"

sam a écrit :
> Bruno Desthuilliers napisa³(a):
> 
>
> Thanks for precise opinion and spending your time.
>
>
> I think that when you use statically typed language, than you have to
> define classes, because compiler has to know what is allowed to do with
> instances of that class.
>
> But when you use dynamically typed language, then classes are redundant,
> because object is looked at when it is referenced. Dynamically typed
> language needs only objects hierarchy and you can add properties
> (methods, values) to that object during program execution.

Dynamic typing does not necessarily imply that you can add properties of
modify behaviour at runtime. Most dynamically typed languages let you do
that, but that's still orthogonal. And FWIW, you could emulate this in
static languages using a hashtable, functors, and a couple accessors (a
la __getattr__/__setattr__).

> In dynamically typed language when you create object A that is inherited
> from another object B,  than object A knows that B is his predecessor. So
> when you reference A.prop, then prop is looked in A first, then in B,
> then in predecessors of B, and so on.

What you're describing here is the inheritance mechanism of Python. And
could apply just as well to javascript prototype mechanism. A javascript
object has a reference to it's prototype object - that you can
customize, rebind etc -, a Python object has a reference to it's class
object - that you can customise, rebind etc...

Don't be fooled by the term "class" itself - it's meaning is totally
different in a language like Python. I may be plain wrong here but I
suspect you don't have a serious knowledge of Python's object model.

Bruno Desthuilliers napisa³(a):
 
>
> What you're describing here is the inheritance mechanism of Python. And
> could apply just as well to javascript prototype mechanism. A javascript
> object has a reference to it's prototype object - that you can
> customize, rebind etc -, a Python object has a reference to it's class
> object - that you can customise, rebind etc...

I can see that Python and Javascript inheritance model is almost the same. B
oth
languages are dynamically typed. And it seems that using "classes" in Python
makes some things more complicated then it is necessary (eg functions, metho
ds
and lambdas are differen beeing in Python concept).



> Don't be fooled by the term "class" itself - it's meaning is totally
> different in a language like Python.

Probably I'm not alone. Many people who think dymanic types are Rhight Thing
 in
programming will also prefer prototype-based programming to class-based.




> suspect you don't have a serious knowledge of Python's object model.

Yes -- I'm new to Python.

On Fri, 21 Mar 2008 11:43:33 +0100, sam wrote:

> I can see that Python and Javascript inheritance model is almost the
> same. Both languages are dynamically typed. And it seems that using
> "classes" in Python makes some things more complicated then it is
> necessary (eg functions, methods and lambdas are differen beeing in
> Python concept).

Please explain why you think that functions are more complicated in
Python because of the class model.



--
Steven

> I can see that Python and Javascript inheritance model is almost the
> same. Both languages are dynamically typed. And it seems that using
> "classes" in Python makes some things more complicated then it is
> necessary (eg functions, methods and lambdas are differen beeing in
> Python concept).

Sorry, but that is utter nonsense. It begins with the fact that there is
no "inheritance model" in Javascript. Or why does each JS-lib provide
it's own version of an extend-function [1]? Which one has to grasp
before really being able to use inheritance in JS. And of course
everybody does it a bit different, including possible access to parent
classes and such. Calling that an advantage is rather bold.


And it continues with the abnomination the implicit "this" in Javascript
is - e.g. MochiKit offers a bindThis-method to ensure that a method-call
always gets the actual instance passed as this - something that can get
"lost" when dealing with event-handling. Whereas python here offers the
bound-method-concept.

The only point you might have is the somwhat unfortunate distinction
between lambda and function in python - but this is on a syntactical
level only. Once created, you can use them as you like.

I do like JS for what it is - but everybody who uses it in an OO-manner
ends up inventing the same wheels Python already comes with.

Diez

[1] Just one example: http://docs.mootools.net/Class/Class.js

On Mar 21, 11:48 pm, "Diez B. Roggisch" <de...@nospam.web.de> wrote:

> [1] Just one example:http://docs.mootools.net/Class/Class.js

Mootools being something a coworker might use?

John Machin schrieb:
> On Mar 21, 11:48 pm, "Diez B. Roggisch" <de...@nospam.web.de> wrote:
> 
>
> Mootools being something a coworker might use?
>

I don't understand the question.

Diez