B
Bruno Desthuilliers
MonkeeSage a écrit :
Fine. So we may have a chance to get out there !-)
(snip)
Nope. We've been thru the distinction between a callable attribute and a
methodin another nearby thread, so won't come back on this. wrt/ mro,
it's being used for *all* attributes. That is, the look up rule for an
attribute is :
1. instance's __dict__
2. class's __dict__
3. all classes __dict__s in the class's mro
NB : not taking __getattribute__ and __getattr__ hooks into account here.
Not for me, sorry - my time to deal with my own ignorance !-)
For a definition of attribute being different from 'member variable'.
But what we disagreed was more about the definitions of 'attribute' and
'callable' !-)
You still have both a member variable and an 'attribute'. And the member
variable is stored in the instance, while the 'attribute' (that is, the
getter and setter methods) are stored with the class. From this POV,
this is the equivalent of the Python snippet using a property.
The WTF was about the class attribute. Did you try it with a mutable
object instead of a string, and more than one instance ?-)
That's why I think the important point here is the semantic, not the
implementation (while talking about the method/non-method distinction in
Python is clearly about implementation).
You don't have to be sorry. We're both guilty (if guilty of anything)
and honestly, I tend to be a bit on the nit-pick side, which sometimes
doesn't help.
Thanks for the precisions.
regards,
Fine. So we may have a chance to get out there !-)
(snip)
Nope. We've been thru the distinction between a callable attribute and a
methodin another nearby thread, so won't come back on this. wrt/ mro,
it's being used for *all* attributes. That is, the look up rule for an
attribute is :
1. instance's __dict__
2. class's __dict__
3. all classes __dict__s in the class's mro
NB : not taking __getattribute__ and __getattr__ hooks into account here.
Not for me, sorry - my time to deal with my own ignorance !-)
class Arequire 'parse_tree' => true
ParseTree.translate(%q{
def foo
"bar"
end
end
A.new.foo})
=> [:block, [:class, :A, nil, [:scope, [:defn, :foo, [:scope, [:block,
[:args], [:str, "bar"]]]]]], [:call, [:call,
[:const, :A], :new], :foo]]
Notice that #new and #foo are both CALL ops. All attribute access is
CALL (i.e., "method"). There really is no such thing as a non-callable
"attribute" in ruby.
For a definition of attribute being different from 'member variable'.
But what we disagreed was more about the definitions of 'attribute' and
'callable' !-)
You still have both a member variable and an 'attribute'. And the member
variable is stored in the instance, while the 'attribute' (that is, the
getter and setter methods) are stored with the class. From this POV,
this is the equivalent of the Python snippet using a property.
The WTF was about the class attribute. Did you try it with a mutable
object instead of a string, and more than one instance ?-)
That's why I think the important point here is the semantic, not the
implementation (while talking about the method/non-method distinction in
Python is clearly about implementation).
You don't have to be sorry. We're both guilty (if guilty of anything)
and honestly, I tend to be a bit on the nit-pick side, which sometimes
doesn't help.
Ps. To answer a question you asked, "callable" objects don't generally
implement a #call method--just Proc objects and method references
[class Method instances] do, which even though they have a #call
method, aren't usually considered "callable" since you can't call them
directly--the #call method could as easily be named #run or #evaluate
or whatever. Accessing a name in ruby basically does something like:
VCALL name (== if parens on name like a() skip to call step, otherwise
check for LVAL in scope and return value if found, otherwise FCALL/
CALL and return result). You can use the #define_method method to
create a new "callable."
Thanks for the precisions.
regards,