Re: Re: vote on prop keyword

I wish I could give straighter answers rather than questions...sorry!

Mark Hahn wrote:

> Paul Prescod wrote:
> 
> 
>>Anyhow, I think that a) the "prop" keyword is a good way of hiding the
>>underlying machinary and b) the underlying machinary is probably fine
>>but it just took me by surprise at first because it uses inheritance
>>instead of either "special" slots (which I would expect from a
>>language like Java) or wrapper objects (which I expect from Python).
> 
> I never did understand the Python wrapper object mechanism or I might have
> considered it.  Does it have any advantages?

Maybe subtle ones. Python's model is tied to its class system. At the 
class level a property is just another object. It is only treated 
specially when you access it through an instance. One nice thing is that 
you can work with the object as a property or not a property depending 
on how you grab it. But it is hard to know how to import that into a 
prototype system:

 >>> class Foo(object):
...     def getx_(self): return "Got x"
...     def setx_(self, val): print "Set x"
...     x = property(getx_, setx_)
...
 >>> Foo.x
<property object at 0x44fa08>
 >>> temp = Foo.x
 >>> Foo.x = 5
 >>> Foo.x
5
 >>> Foo.x = temp
 >>> foo = Foo()
 >>> foo.x
'Got x'
 >>> foo.x = 5
Set x
 >>> foo.__class__.x
<property object at 0x44fa08>
 >>> foo.__class__.x = 6
 >>> foo.x
6

 >...
> Detecting a specific type by the interpreter can be done in one comparisom.

Even with multiple inheritance?

> Also I think my method is pretty clear and intuitive.  If tax "is a
> property" then shouldn't it be a "Property" through inheritance?

Python does not use inheritance for much internally. It very seldom says 
things like: if you want to use X for purpose Y then X must be a 
subclass of Z.

When my object "inherits" from Prop, what does it get from Prop? Just a 
type flag?

I also notice that prothon does not treat properties specially when they 
are accessed through module objects.

paul:/tmp pprescod$ cat ./myprop.pr

object foo(Prop):
     def get_(): print "Get foo"
     def set_(): print "Set foo"


paul:/tmp pprescod$ cat ./test.pr
#!/usr/local/bin/prothon

import myprop

x = myprop.foo()
print x

paul:/tmp pprescod$ ./test.pr
<Prop>

Not sure how I feel about that. It is a little inconsistent and it means 
that modules can't have properties. On the other hand if it did treat 
them as it does in object context that would cause a bunch of other 
problems. ;)

The underlying problem with properties is that they are really just 
syntactic sugar that have subtle implications for the underlying model 
and language.

Okay, here's an attempt at a solution...

====

Every object, including modules, has a props_ sub-object.

object X:
     def get_(): ...
     def set_(): ...

myobject.props_.x = X

import mymodule

mymodule.props_.x = X

You can replace a property through that sub-object.

myobject.props_.x = Y

Since properties would not be a kind of type, you could store them on an 
object either directly or through attrs_ without having them act like 
properties. If you want them to be treated as a property of a PARTICULAR 
object you say so explicitly by assigning them to props_.

And of course under the syntax sugar "prop" could still exist although 
it would be very thin. It would stand for:

object X:
     object props_.x:
         ...

In a sense this is more Prothonic because Prothon has many magic 
attributes but few magic prototypes. And I *think* it makes modules and 
objects more symmetric.

  Paul Prescod