> 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".
> ...
Yes, this is a good example of where such syntactic micro-magic can be a
very pleasant experience for the user. I think the cases of properties
that both Jeroen and Erik are arguing to allow are exactly things like
this. It seems that possible doc-issues can be managed, more or less.
So I concede that the rigid stance of officially disallowing all
properties would be "asking for trouble". Perhaps a more realistic
stance is something like:
[ ] Rule of thumb: don't use properties, except if there is a clear,
syntactic benefit that presents a logical exception (to the "method
default") for the user. Properties should particularly be avoided if
exceptions could be thrown or heavy computation performed.
OK, so that's not perfectly well-defined either, but at least things
like MPolynomialIdeal.basis should be method'ized by this rule, as
should the list of properties in the recent AsymptoticRing class (e.g.
summands, growth_group, coefficient_ring, ao.).
Going back to Matrix, I would argue that Matrix.T, Matrix.H, etc. also
fall for this rule. Certainly, Matrix.I does.
Best,
Johan
--
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.
