Anonymous attribute/property possible?

[Bengt Richter]

On Mon, 11 Mar 2002 10:46:13 GMT, Michael Hudson <mwh at python.net> wrote:

>bokr at oz.net (Bengt Richter) writes:
>
>> A class with an anonymous attribute/property would provide a place to put
>> get/set/del-triggered code.
>> 
>> Use of an object with an anonymous property in an expression
>> or statement would result in calling the get/set methods defined.
>> 
>> Thus you could write foo(bar) with the effect of foo(bar.__anonymous__)
>> and bar() with the effect of bar.__anonymous__()
>> 
>> And bar = baz with the effect of bar.__anonymous__ = baz.
>> 
>> But since __anonymous__ could be a property, you could define
>> methods at will (e.g., get_bar, and set_bar) and write
>> bar = baz with the effect bar.set_bar(baz) and
>> foo(bar) with the effect foo(bar.get_bar())
>> 
>> This might work nicely with an interpolated-string class.
>> E.g.,
>>   is = IS('The get_is anonymous property method will interpolate $variables')
>>   print is # the reference would trigger interpolation with current values
>>            # you could do this now, but you'd have to write "print is.some_property"
>> 
>
>Ouch.
>
Where does it hurt ;-)

>> If you wanted to access the actual object that had an anonymous
>> property, you'd have to give it a named method returning self for
>> that purpose.
Or obj.self, better.
>> 
>> I think this could open up a whole world of scary delights ;-)
>> (And ISTM without a backwards compatibility problem).
>
>Just in case the fact that this is a horrible idea doesn't put you off
><wink>, how would you implement this without a fairly huge performance
>hit?  LOAD_FAST is currently, well, fast.
>
Well, I was avoiding premature optimization ;-)

I'm not seriously advocating this. I just wanted to explore the notion
a little. I should look at the code, but if LOAD_FAST gets a pointer
to the object representation, it might not be so bad to check a boolean
value cached therein to see if __anonymous__ magic was associated.

I'm not suggesting a lookup in the object's attribute dict to see if it has
the __anonymous__ attribute at run time. Adding or deleting .__anonymous__
dynamically would have restrictions. I'm thinking a flag bit in some standard
lowlevel object representation slot indicating presence of the __anonymous__
attribute, which could be checked with a test and jump (if there is already a
representation type code used in a switch, maybe a new case wouldn't add any new
overhead).

You might need a LOAD_SELF byte code for references to the object itself where
*no* __anonymous__ flag check was to be made, which the compiler would
generate from a reference to obj.self as a reserved attribute name. Thus obj.self
would generate LOAD_SELF obj and obj would generate LOAD_FAST obj.

Anyway, if the flag was set, it would mean that there was an implicit
LOAD_ATTR or STORE_ATTR using __anonymous__, which could presumably share
normal code for those.

Thinking-via-the-keyboard-again-ly ;-)

Regards,
Bengt Richter