Re: Proposal to Improve <at> Property Syntax
On 4/19/06, Jochen Theodorou <blackdrag@...> wrote:
> Graeme Rocher wrote:
> > On 4/17/06, Jochen Theodorou <blackdrag@...> wrote:
> >>Graeme Rocher wrote:
> >>>Not to put pressure on or anything but, unless you can put forward
> >>>a valid argument against I think we should proceed with this change
> >>>now as the rest of the groovy development team is in agreement on it.
> >>not all ;) I just didn't vote against it
> > Fair enough :) but there has yet to be a conclusive argument against..
> > and we keep waiting
> Grame, the pro as well as the con arguments are evry weak. So it is more
> a matter of taste and the things I expect. If you see a property as
> "more", then it is hard to understand, that doing "less" will create
> "more". And if you see fields as "more" all is fine.
I don't see the pro argument as being weak, the pro argument has so far covered:
- how <at> Property is not elegant
- how it does not comply with the real use of annotations
- how its not a replacement for AST macros
- how the semantics will work with the change
- what could potentially be broken
- probably more i'm forgetting, but there was lots in the thread
The con argument has covered...ummm... what has it covered? The only
thing i can think of is that it may be surprising to a user if it
overrides a super class getter/setter
> A matter of taste, just as I said.
Yes this i agree with
> As long as it doesn't matter if there is a property or a filed, there is
> no problem and I think in most cases this will not really be a matter.
> bye blackdrag