Re: Re: vote on prop keyword

Paul Prescod wrote:
> Mark Hahn wrote:
>
>> ...
>>
>> Why are you using myprop.foo as a protoype?  Myprop.foo works fine
>> for me:
>>
>>>> import myprop
>>>> print myprop.foo
>> Get foo
>
> Good point. Do I understand that in the future my error would raise an
> exception? If an object is not explicitly marked as a prototype then I
> guess it won't be callable, right?

Hmm.  Should your code have worked?  call_ works on all objects.  What it
did was make an instance that had the property object foo as a prototype.
Should the call_ lookup of foo have triggered the property mechanism
instead?

Right now I have two ways in C of looking up an attribtute.  One is higher
level than the other.  The call_ code is using the low-level lookup right
now.  There are probably other places like this in the code.  Is this a
problem?

I guess only the obj.attrs_ access method show go around the prop mechanism.
Everything else visible to the Prothon language should go through the
properties mechanism, right?

>> I didn't look at your proposal because I assumed it was to fix my
>> non-existant problem.  Do you still want me to give it a look?
>
> #1. I think it is slightly un-Prothonic and un-Pythonic to have magic
> base classes. Magic properties are more common in the language.

What is a "magic property"?

> #2. When it is a property of the object you have to be careful with
> those objects if you want to pass them around in various contexts. For
> instance a pickler might have code like:
>
> #!/usr/local/bin/prothon
>
> object pickler:
>     object_I_am_working_with = None
>
>     def init_(obj):
>         self.object_I_am_working_with = obj
>
>     def pickle():
>         # would of course do something more interesting
>         print self.object_I_am_working_with.protos_
>
> p = pickler(5)
> p.pickle()
>
> If obj happens to be a property then it will start to have "property
> behaviour" in this context just because it happens to be stored in an
> attribute on an object. The code will work great until "obj" happens
> to be a property.
>
> object problem(Prop):
>      pass
>
> p = pickler(problem)
> p.pickle()
>
> This would not be a problem with my proposal. The code would only take
> on property behaviour in a context where you explicitly tell it to.

Your proposal is basicly this (correct me if I'm wrong):

object Widget:
      object tax:
            object props_:  # magic attribute name
                   object x:
                       object Y:
                              def get_():
                                    blah blah blah

Let's assume that all the middle levels aren't necessary:

object Widget:
      object tax:
            object props_:  # magic attribute name
                  def get_():
                         blah blah blah

So now we have something like my use of command_ or other attribute
proposals from the past.  I will have to check on each attribute lookup to
see if that attribute has its own attribute named "props_".  It will be
slower than the magic prototype I have now but I'm not supposed to worry
about performance for now.  Tricks can be done.

After typing this I realize I don't understand your proposal at all.  What
in the heck does "myobject.props_.x = Y" mean?  None of the terms are
defined.