Il 02/05/2012 22:00, Anthony Liguori ha scritto:
>>
>> Not really, in fact this kind of class-side data is really bread and
>> butter
>> of all dynamic languages, and it's how most of them implement
>> polymorphism.
>> They have an associative array (method names -> method bytecode for
>> example)
>> in each class on the hierarchy, and walk the hierarchy for each
>> function call.
>
> I'm not aware of any language that does this.
Python:
class A:
def a(self):
return "a"
class B(A):
def b(self):
return "b"
B.__dict__
# {'__module__': '__main__', 'b': <function b at 0x7f9308aab668>,
'__doc__': None}
print(B().b())
# b
B.__dict__["a"]
# Traceback (most recent call last):
# File "<stdin>", line 1, in <module>
# KeyError: 'a'
print(B().a())
# a
Smalltalk:
'abc' class
# String
String methodDictionary includesKey: #==
# false
Object methodDictionary includesKey: #=
# true
Ruby too:
class A
def a() end
end
class B < A
def b() end
end
B.instance_methods
# [:b, :a, :nil?, :===, :=~, ...]
B.instance_methods(include_super=false)
# [:b]
but I don't know exactly how to access the dictionary here.
> Many languages today have an associative array in the object. It's
> filled out from a class definition during instantiation. This is what
> allows monkey patching.
That's just Javascript as far as I know. Python has an associative array
in the object _and_ one in the class, and they aren't exactly the same
thing:
class A:
def a(self):
return "a"
A.__dict__
{'a': <function a at 0x7f67c8dc1578>, '__module__': '__main__', '__doc__':
None}
x = A()
x.__dict__
# {}
x.a()
# 'a'
x.__dict__["a"] = lambda self: self
x.__dict__
# {'a': <function <lambda> at 0x7f67c8dc1500>}
x.a()
# Traceback (most recent call last):
# File "<stdin>", line 1, in <module>
# TypeError: <lambda>() takes exactly 1 argument (0 given)
x.a('look, no implicit self anymore!')
'look, no implicit self anymore!'
y = A()
y.a()
# 'a'
Ruby has an associative array in the object and one in the class, and they
work as expected:
class A
def a() end
end
x = A.new
# <A:0x000000027e0db8>
x.a
# nil
x.define_singleton_method("a") { puts "i'm special" }
x.a
# i'm special
# nil
x.singleton_methods
# [:a]
y = A.new
y.a
# nil
y.singleton_methods
# []
> Classes are first class objects and can contain members, but I don't
> know of any system where you actively look at the same field in a
> super class for each class in the hierarchy. That's really trippy.
Just because it's new to you. Smalltalk has been doing that for 30-odd
years.
Of course the VM has a lot of caching going on, but it's entirely
internal.
> If we move properties to Object, I'd rather just stick a property
> pointer in TypeInfo and call it a day. I'm not thrilled about it, but
> I feel a lot better about it the above.
What if we add declarative links or children, for example? Adding more
junk to TypeInfo is not the solution.
Paolo
