Re: [Qemu-devel] [PATCH 11/21] qdev: move bus properties to abstract superclasses

[Paolo Bonzini <pbonzini@redhat.com>]

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