On Fri, Apr 29, 2016 at 09:31:31AM +0200, Johan S. R. Nielsen wrote:
> I call for the following vote:
>
> [ ] Phase out all uses of properties in the public API and make them
> into methods that take no arguments. Add in the developer's manual
> somewhere that this is the general policy.
>
> [ ] Phase out properties which perform any non-trivial computation, and
> officially condone the use of properties as "getters" of trivial
> private information.
>
> [ ] Phase out properties that might (expectedly) throw exceptions, such
> as Matrix.I. Condone the use of properties as "getters" of derived
> information, such as Matrix.T (transpose).
>
> [ ] Keep things as they are.
>
>
> For the record, my vote is on phasing out all properties.
Consistency is a definitive plus, as well as not impeding
introspection. So I would tend to agree to officially phase out
properties from the public API.
There is one use case for properties in the public API though which I
would like to bring up, namely "glorified methods". Let me explain:
Let P be a parent, and f be a morphism naturally attached to P.
Typical examples are P.product, P.coproduct, ... User wants to:
- use the morphism as a function and apply it on elements
- do operations on the morphism (e.g. compute its rank)
In the current instances, the construction of the morphism may be non
trivial (e.g. define the morphism by linearity), but is cheap (at the
scale of user interaction, e.g. tab completion), and does not raise
exceptions (unless the code is broken in the first place).
In several places, we have used the following convention:
P.f(x) # use the morphism as a function
P.f.rank() # play with the morphism itself
To achieve this, P.f is actually a property (typically a
lazy_attribute), that constructs the morphism.
Alternative syntaxes would be:
P.f()(x) # use the morphism as a function
P.f().rank() # play with the morphism itself
P.f(x) # use the morphism as a function
P.f_morphism().rank() # play with the morphism itself
The merits of the syntax we use are:
- For beginners P.f just feels like as a usual method. When they need
more, they can realize that P.F is actually more than a method
- We don't pollute P's namespace with two gadgets for just one thing.
This is a use case of properties in the public API which I would like
to keep as an exception. Other exceptions of course are the usage of
properties for implementing meta-stuff, like cached_methods, abstract
methods, conditionally defined methods, etc.
I don't have a strong opinion about properties for private
attributes. It seems reasonable indeed to request that they should not
raise exceptions nor do lengthy computations.
Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" <nthi...@users.sf.net>
http://Nicolas.Thiery.name/
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
