Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Prototype based vs. class based inheritance

stackoverflow.com

Post reply on HN
Print view View original

11–20 of 26 posts

Re: Prototype based vs. class based inheritance

#11

Post by wladimir »

wvenable wrote: post #5
russellallen wrote: post #4

Some thoughts: Given a sufficiently flexible and late-bound class system (like Smalltalk's), the differences between prototypes and classes can blur. But in general I would say that it is easier to build classes on top of prototype systems than vice versa, which is one argument for prototypes. All prototype implementations aren't the same, though, any more than Smalltalk and C++ both have the same class systems! Java…

> What attracts me most is that prototype systems are conceptually simpler in an Occam's Razor sort of way. That's true, but I find you end up having to make the difference. Yes, prototype inheritance is conceptually simpler but in practice it's more complex. In JavaScript, for example, OO code tends to be harder to follow and includes more boilerplate code. You have to make up for the simplicity of the platform in o…

Javascript also severly biased me against prototype-based and for class-based inheritance.

Then again, Javascript's implementation of anything is awful. The only reason people use it, is because there is no way around it for web client programming. I'm pretty sure we shouldn't take it as an example.

Re: Prototype based vs. class based inheritance

#12

Post by btilly »

wvenable wrote: post #5
russellallen wrote: post #4

Some thoughts: Given a sufficiently flexible and late-bound class system (like Smalltalk's), the differences between prototypes and classes can blur. But in general I would say that it is easier to build classes on top of prototype systems than vice versa, which is one argument for prototypes. All prototype implementations aren't the same, though, any more than Smalltalk and C++ both have the same class systems! Java…

> What attracts me most is that prototype systems are conceptually simpler in an Occam's Razor sort of way. That's true, but I find you end up having to make the difference. Yes, prototype inheritance is conceptually simpler but in practice it's more complex. In JavaScript, for example, OO code tends to be harder to follow and includes more boilerplate code. You have to make up for the simplicity of the platform in o…

In more traditional OO languages, inheritance might be more limited...

Explain.

Class based inheritance, with a good metaprogramming model, is strictly more flexible than prototype based inheritance because you can easily implement the latter. The shortest implementation that I know of is the following Ruby one:

  Proto = Class.new(Class)    # Beware: magic.
  def Proto.clone
      Class.new(self)
  end
You can find out more about how to use that at http://snippets.dzone.com/posts/show/3378.

Re: Prototype based vs. class based inheritance

#14

Post by troels »

btilly wrote: post #12
wvenable wrote: post #5

Earlier quoted context omitted.

> What attracts me most is that prototype systems are conceptually simpler in an Occam's Razor sort of way. That's true, but I find you end up having to make the difference. Yes, prototype inheritance is conceptually simpler but in practice it's more complex. In JavaScript, for example, OO code tends to be harder to follow and includes more boilerplate code. You have to make up for the simplicity of the platform in o…

In more traditional OO languages, inheritance might be more limited... Explain. Class based inheritance, with a good metaprogramming model, is strictly more flexible than prototype based inheritance because you can easily implement the latter. The shortest implementation that I know of is the following Ruby one: Proto = Class.new(Class) # Beware: magic. def Proto.clone Class.new(self) end You can find out more about…

Well, Ruby's classes are open. So while they are called classes, they are much more similar to prototypes than, say, Java's classes are.

Re: Prototype based vs. class based inheritance

#15

Post by eliben »

mln wrote: post #3

this is what Guy Steele has to say. http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m...

One of the links from this page mentions this: http://okmij.org/ftp/Scheme/oop-in-fp.txt, where the author presents a simple example of implementing an object using closures:

  (define (make-point-2D x y)
    (define (get-x) x)
    (define (get-y) y)
    (define (set-x! new-x) (set! x new-x))
    (define (set-y! new-y) (set! y new-y))
    (lambda (selector . args)     ; a dispatcher
        (case selector
          ((get-x) (apply get-x args))
          ((get-y) (apply get-y args))
          ((set-x!) (apply set-x! args))
          ((set-y!) (apply set-y! args))
          (else (error "don't understand " selector)))))
Which is curiously similar to the canonical object implementation of SICP in section 3.2:

  (define (make-account balance)
    (define (withdraw amount)
      (if (>= balance amount)
          (begin (set! balance (- balance amount))
                 balance)
          "Insufficient funds"))
    (define (deposit amount)
      (set! balance (+ balance amount))
      balance)
    (define (dispatch m)
      (cond ((eq? m 'withdraw) withdraw)
            ((eq? m 'deposit) deposit)
            (else (error "Unknown request -- MAKE-ACCOUNT"
                         m))))
    dispatch)

Re: Prototype based vs. class based inheritance

#16

Post by btilly »

troels wrote: post #14
btilly wrote: post #12

Earlier quoted context omitted.

In more traditional OO languages, inheritance might be more limited... Explain. Class based inheritance, with a good metaprogramming model, is strictly more flexible than prototype based inheritance because you can easily implement the latter. The shortest implementation that I know of is the following Ruby one: Proto = Class.new(Class) # Beware: magic. def Proto.clone Class.new(self) end You can find out more about…

Well, Ruby's classes are open. So while they are called classes, they are much more similar to prototypes than, say, Java's classes are.

FYI, Ruby's class model is almost directly copied from Smalltalk, which is the classic object oriented language, and is where the phrase "object oriented" was invented. Therefore there are no grounds to suggest that Ruby somehow does not have "real" classes because they don't look like Java's.

Re: Prototype based vs. class based inheritance

#17

Post by troels »

btilly wrote: post #16
troels wrote: post #14

Earlier quoted context omitted.

Well, Ruby's classes are open. So while they are called classes, they are much more similar to prototypes than, say, Java's classes are.

FYI, Ruby's class model is almost directly copied from Smalltalk, which is the classic object oriented language, and is where the phrase "object oriented" was invented. Therefore there are no grounds to suggest that Ruby somehow does not have "real" classes because they don't look like Java's.

I weren't proposing any form of value with my statement. Just pointing out that on the scale of {run-time..compile-time} object model, Ruby is closer to the run time end.

Re: Prototype based vs. class based inheritance

#18

Post by demallien »

silentbicycle wrote: post #2

See: http://www.c2.com/cgi/wiki?ClassesPrototypesComparison In my experience, prototype-based OOP is less prone to the typical OOP over-analysis - if you just need one object that does something, you just assemble it, that's it, problem solved . Since the default stance isn't designing a generic class for all possible subtypes that exhibit related behavior and blah blah blah, there's less push toward overthinking thi…

In my experience, prototype-based OOP is less prone to the typical OOP over-analysis - if you just need one object that does something, you just assemble it, that's it, problem solved. Since the default stance isn't designing a generic class for all possible subtypes that exhibit related behavior and blah blah blah, there's less push toward overthinking things.

But that's not really a property of prototype languages - it's a property of duck typing. For example, Ruby - a non prototype language - can implement exactly the same idea. Take an instance of a class, and add a method specifically to that object - no problems. Critically, the thing that makes this possible is the fact that evaluation of the existence of the method is made at call time, not at compile time.

Re: Prototype based vs. class based inheritance

#19

Post by BigZaphod »

russellallen wrote: post #4

Some thoughts: Given a sufficiently flexible and late-bound class system (like Smalltalk's), the differences between prototypes and classes can blur. But in general I would say that it is easier to build classes on top of prototype systems than vice versa, which is one argument for prototypes. All prototype implementations aren't the same, though, any more than Smalltalk and C++ both have the same class systems! Java…

I've always understood it to be that prototypes are a superset of classes.
Post reply on HN