Prototype Based Object

My friend Dave Fayram (who helped bring advanced LSI classification to Ruby’s classifier) has heeded Matz’s advice to learn Io and is bringing me with him. I have been thinking a lot about prototyped versus class-based languages lately and once I really understood it, I fell in love. I have a feeling I will be writing a lot about this topic, but here is a brief introduction.

# Class-based Ruby

class Animal
  attr_accessor :name
end

# A class can be instantiated
amoeba = Animal.new
amoeba.name = "Greenie"

# A new class needs to be defined to sub-class
class Dog < Animal
  def bark
    puts @name + " says woof!"
  end
end

# A sub-class can be instantiated
lassie = Dog.new
lassie.name = "Lassie"
lassie.bark # => Lassie says woof!

Notice in the Io version that you never ever define a class. You don’t need to.

# Prototype-based Io

Animal := Object clone

# An object can be instantiated
amoeba := Animal clone
amoeba name := "Greenie" 

# An object can be used to sub-class
Dog := Animal clone
Dog bark := method(
  write(name .. " says woof!")
)

# An object can be instantiated
lassie := Dog clone
lassie name := "Lassie" 
lassie bark # => Lassie says woof!

You will notice some syntactical differences immediately. First, instead of the dot (.) operator, Io uses spaces (note: technically, with a couple lines of Io you can actually make Io use the dot operator or the arrow operator (->) or anything else you would like).

Next, you will notice that instead of making a new instance of a class, when you use prototype-based languages you clone objects. This is the foundation of prototyping… defining classes is unnecessary, everything is just an object! Furthermore, every object is essentially a hash where you can set the values of the hash as methods for that object.

You get a sense for this kind of idea in Ruby when you do this:

class Hmm
end

Hmm.class # => Class

So the class of the Hmm class is a class… classes are instance objects of Class. In short, almost everything in Ruby is an object already, except whas is the class of Class?

Class.class # => Class

If you have never seen this before, you might want to take a minute to recuperate from the aneurism this should have caused. If fact, this is a conundrum found in all class-based programming languages and is solved in various different ways (in Ruby, Matz chose to solve this paradox by making Class a singleton class).

The important part to take away from this discussion is that almost everything in Ruby is an object, even classes. Prototyping embraces this fact and takes it the last step necessary for the abstraction and completely removes the distinction between a class and an object. Once you see it this way, you will notice that having classes at all is a crutch… an unnecessary layer that doesn’t add to object-oriented programming… in fact it makes things more confusing to have the separation at times.

How could class-based programming make things more confusing you ask? The answer lies in metaprogramming. Metaprogramming in Ruby can be beautifully easy. Here is a canonical example:

# Meta-programming-free
class Foo
  def bar
    @bar
  end
  def bar=(bar)
    @bar = bar
  end
end

# Meta-programming added with the method "attr_accessor"
class Foo
  attr_accessor :bar
end

However, more involved metaprogramming, like that found in Rails’ ActiveRecord implements metaprogramming for thing like has_many in the following way.

module AnimalSounds
    def bark
        puts "woof"
    end

    def self.append_features(base)
        super
        base.extend(ClassMethods)
    end
    module ClassMethods
        def create_sound(attr_name)
            define_method(attr_name) { puts "Method #{attr_name} called" }
        end
    end
end

class Pet
    include AnimalSounds
    create_sound :meow
end

fido = Pet.new
fido.bark
fido.meow

The implementation of create_sound is very convoluted, though in the end we are left with a very nice interface. The convolution is birthed from the separation between classes and instances in Ruby. When you give up your grasp of classes and enter the world of prototyped languages, metaprogramming at this level falls into place much easier and cleaner.


AnimalSounds := Object clone

AnimalSounds bark := "woof" 

AnimalSounds createSound := method(attrName,
  self setSlot(attrName, block("Method " .. attrName .. " called"))
)

Pet := Object clone appendProto(AnimalSounds)
Pet createSound("meow")

fido := Pet clone
fido bark
fido meow

Interesting, isn’t it. I wonder what Rails’s ActiveRecord and it’s engines would look like in Io, don’t you?

As a final mention to the power of prototyping, I would like to mention ActionScript, which is Macromedia’s programming language available within Flash. On the face of it, it looks like any other class-based programming language, but the class of Class paradox is mute because ActionScript a prototype-based language. The “Class” is basically a clone of an Object. Think on that. Classes are just a prototype pattern.

Posted in Io, Programming, Ruby | 14 comments

Comments

Leave a response

nuke edit
Blaine Cook said about 1 hour later:
ActionScript := ECMAScript clone appendProto(flashInterface)

JavaScript := ECMAScript clone appendProto(browserInterface)

So that’s why I like JavaScript so much…

:-)
nuke edit
Erwin Lech said about 16 hours later:
So does this mean JavaScript is a prototype based language too?
nuke edit
Lucas Carlson said about 16 hours later:
Yes, JavaScript is prototype-based and very fun to work with when you discover that. :)
nuke edit
topfunky said about 19 hours later:
Totally off topic, but this is a beautiful theme and it’s great to see it in use!
nuke edit
John Nowak said 2 days later:
This is my main reason for using Io. I simply cannot use Python or Ruby at this point (not that I ever could—I used Scheme prior). The syntax is general is also beautiful.
That said, Io still has some rough edges, as it is a very young language. On the plus side though, that means you can join in and help resolve the remaining issues in a way you find most agreeable. Go on… give it a shot…
nuke edit
Dennis said 2 days later:
Recently I was playing with Squeak Smalltalk. It’s a live system, you make changes to the image as it runs. I added a couple properties to the Character class (author, createdate). Immediately, the properties were available in every character in the system…all the dev tools I was running, the text editors, everything using characters now had the new properties available.

Would something like this work in a prototype-based language? If not, Smalltalk classes aren’t just a prototype pattern.

(In any case, Io sure is intriguing.)
nuke edit
Lucas Carlson said 2 days later:
Yes, inheritance works just as well in prototype-based languages. Add a couple methods to the Object class and you get them everywhere.
nuke edit
Dennis said 2 days later:
Forgive me being dense, but if you clone bar from foo, and later add a property to foo, does it show up in the already-created bar? (Ie., the cloned object maintains a reference to the object it was cloned from, rather than simply copying it?)
nuke edit
Lucas Carlson said 2 days later:
No need to apologize. The answer is yes, but don’t take my word for it, download and try for yourself: http://iolanguage.com/downloads/
nuke edit
Dennis said 2 days later:
Thanks. Good idea :) Although I’m a little worried that after I try it I won’t be happy with anything else!
nuke edit
Jeremy Voorhis said 6 days later:
So clone is not so much a deep copy of an object as it is a quasi-inheritence mechanism.

To make sure I understand correctly…
1. Adding methods and properties to an Io object is very much akin to calling define_method and friends within instance_eval in Ruby.
2. Clone acts as if it is creating a deep copy until you add methods or properties to a cloned object, then it acts more similarly to a superclass in Ruby. If so, that was what I did not understand yet about prototype-based programming.
nuke edit
Jules said 6 days later:
With prototypes, the relationship between class/superclass is the same as instance/class. An instance has a reference to a class in it, and a class has a reference to its superclass.

So if you have a List object/class, and you create an instance:

myList := List clone

Then myList contains a reference to List. And if a propery/method in myList isn’t found, it looks in List:

List bar := method(“This is bar” print) myList foo := method(“This is foo” print)

myList bar # looks in List mylist foo # looks in myList

So you could argue that myList is a subclass of List. You can subclass it or make an instance:

anotherList := myList clone

So clone returns a fresh object with only one propery: the reference to the superclass.
nuke edit
mre said 34 days later:
If you clone an array containing strings in Ruby and then modify the string objects of the original array with string.gsub!(regex) the string objects of the clone will be modified as well!
nuke edit
phil said 34 days later:
Quite a nifty Actionscript tool btw is the free open-source MotionTwin Actionscript Compiler ( http://mtasc.org , written in OCaml, www.ocaml-tutorial.org). The author is also the driving force behind http://nekovm.org, an interesting virtual machine project for scripting languages & language design.

News	See also	Recommended Books	Recommended Links	Articles	Tutorials	Introductory Courses	FAQs
Javascript	Self					Humor	Etc

Prototype Based Object-Oriented Programming

Traditional OO

The prototype

Old News ;-)

Comments

Amazon.com Books Prototype-Based Programming Concepts, Languages and Applications

Recommended Links