Re: Re: vote on prop keyword

Paul Prescod wrote:

>> Hmm.  Should your code have worked?  call_ works on all objects.
>
> It should not. A key reason for my call_ and str_ proposal was because
> call_ on non-prototypes should throw an exception unless they are
> explicitly supposed to be callable (i.e. have an instCall_ method).

I'm sorry.  You misunderstood.  I meant in this build.  Your call_ str_  fix
isn't implemented yet.

> This is very important because you are going to silently surpress many
> mistakes. Integers, booleans, floats, strings, etc. should not be
> callable.

When your proposal is implemented it will only effect prototypes it is
implemented on.  I assume from your argument here that you want it
implemented on all the basic types.  I have no problem with that.

>> What is a "magic property"?
>
> Sorry I meant "magic attribute". Like attrs_, protos_, typeName_,
> str_, init_, ...
>
> Prothon has TONS of these. But where else in the language is there a
> magical base-class that the language recognizes and treats as
> special. I think it is wrong to switch styles.
>
>>> #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:
>
> You didn't comment on this problem. Do you agree that it is a problem?

At first glance yes.  Enough to get me to look at your proposal, which I
didn't understand.

>> ...
>> 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
>
> Nope.
>
> object Widget:
>      prop tax:
>          def get_(): ...
>
>      prop tip:
>          def get_(): ...
>
>
> Expands to:
>
> object Widget:
>      object props_:
>          object tax:
>              def get_(): ...
>
>          object tip:
>              def get_(): ...
>
> When you look up "Widget.tax" you check "is tax in props_". If yes,
> you treat it as a property. If no, you treat it as an ordinary
> attribute.

Actually I will check for a normal attribute first.  See below.

> Here's how you might implement it: whenever something is assigned to
> "props_", you put a wrapper object in the attrs_ dictionary. Then when
> you go to look up something in the attrs_ dictionary, if you see a
> property wrapper then you know to dispatch to the underlying property.
>
> What I'm trying to accomplish here is to say X is a property for Y
> rather than "X is a property." X could be a property of Y and just a
> plain old attribute of Z.

Ok, I can understand this now.

I don't think it would be easy to guarantee there would never be both an
attribute and a prop with the same name.  Is it ok to say that if there is
both a normal attribute and a property then the normal attribute takes
precedence?  If so this would be more efficient because I would only look in
props_ on a lookup failure.  If not then I would have to check props_ on
every access which would be expensive.  As it is this will potentially
double the number of lookup failures in a chain lookup.

This would definitely beg for the prop keyword.  It would allow changing the
mechanism without changing the docs.

I will go back and revisit your "problem" since your solution is so much
more expensive.  I do understand your solution is more in keeping with my
usage of attributes everywhere else.  This is in an unusually sensitive
place for performance though.