@property needed or not needed?

[Rob T]

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