On Monday, 19 November 2012 at 20:04:24 UTC, Jonathan M Davis
wrote:
The thing is that if @property is really an abstraction for
variables, then it
_doesn't_ make sense to allow both, because it's _not_ a matter
of taste.
Either it's a variable, or it's a function. Not both. And if
it's a variable,
then obviously no parens should be used with it. And if it's a
function, then
obviously parens should be used with it.
That makes perfect sense to me if that's what the meaning of
@property is supposed to be, and if so then it can constrain the
usage to that of a variable, which currently is not the case.
If you're viewing it as just a way to not have to use parens on
functions,
then that's something else entirely. And if that's what we're
looking to
support, then using @property for that makes no sense at all.
That makes sense to me as well, and indicates that the @property
topic is getting mixed up with another topic, which concerns the
optional use of () for empty parameter lists.
What may be forgotten, is that we currently have the ability to
not only drop the (), but also to perform optional assignments,
eg Foo = 23;, without defining a function Foo to be @property.
In one case we're talking about variable abstractions, and in
another case we're talking about simply making () optional, these
are two entirely separate topics that are mangled up together.
I think you understand this already, but perhaps not everyone
else does.
To further complicate things, I find that when deciding to define
a function as @property or not is like trying to decide if Pluto
is a planet or not, it's often not clear which way you should go,
and that may be why I really did enjoy not having to specify
@property to make use of the semantics it (was supposed to)
provide when and where I saw fit to do so.
Personally, I hate the fact it's legal to have any kind of
optional parens. I
think that it's incredibly sloppy and goes against the
abstractions of
variables and functions. I'm all for forcing the full set of
parens in a long
chain of UFCS. But clearly plenty of other folks don't agree.
I seriously don't think you should try to constrain coding style,
instead it makes much more sense to provide the user with a means
to constrain it themselves as they see fit. Look at languages
that constrain coding style too much vs languages that don't, and
consider the popularity among them.
My two cents :)
--rt
