On: The Io Language

[richcollins]

One very simple thing that Io gets right is the unification of instance variables and methods as slots. It lets you override behavior with little friction:

  Person := Object clone do(
    name ::= nil
  
    greeting := method(
      "Hello I'm " .. name
    )
  )
  
  bob := Person clone setName("Bob") greeting
  # => I'm Bob
  
  bill := Person clone
  bill greeting := "Yo"
  bill greeting
  # => Yo

[mapleoin → richcollins]

What am I missing?

  >>> class Person(object):
  ...     def __init__(self, name=None):
  ...         self.name = name
  ...     def greeting(self):
  ...         return "I'm %s" % self.name
  >>> bob = Person("Bob")
  >>> bob.greeting()
  0: "I'm Bob"
  >>> bill = Person()
  >>> bill.greeting = "Yo"
  >>> bill.greeting
  1: 'Yo'

[zephyrfalcon → mapleoin]

Notice that you use bob.greeting() but bill.greeting (without the parentheses), while Io uses the same syntax in both cases. Whether this is good or bad is mostly a matter of preference, I think...

Of course, this implies that Io would need a separate construct to get the value of a slot (e.g. bob getSlot("greeting")), while in Python you'd just use bob.greeting no matter whether greeting is callable or not.

[richcollins → mapleoin]

Your code isn't general. You have to change the interface. In Io is there just one interface (send a message). If the slot identified by the message send is activatable (a method), then it is activated, otherwise it is just returned.

[JoachimSchipper → mapleoin]

I'm not sure, but note that your Python code has to know whether to call greeting or not, while the Io code does the same thing either way.