Re: Re: vote on prop keyword

Mark Hahn 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).

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

object foo: a = 5

b = foo().a() # oops. I'll get "0" instead of "5"

I often call things that I shouldn't or forget to call when I should. 
(especially for things that are property-like). Prothon will silently 
surpress that stuff. This is especially nasty when an integer or flat 
gets replaced with 0.

>>>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"?

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?

>...
> 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.

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.

  Paul Prescod