3 ms·
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:
by richcollins 16y ago
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 16y agoWhat 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'
- richcollins 16y agoYour 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 16y agoI'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.
- zephyrfalcon 16y agoNotice 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.
- mahmoudimus 16y agoHe can just make a property and the interface is satisfied