Re: Proposal to Improve <at> Property Syntax

On 23 Mar 2006, at 15:42, Jeremy Rayner wrote:

> It's a -1 from me, but I haven't had time to formulate my reasoning in
> a good email yet

Jez,

are you able to formulate your objections to this yet?

John Wilson
The Wilson Partnership
web http://www.wilson.co.uk
blog http://eek.ook.org

Re: Proposal to Improve <at> Property Syntax

After this week is over I hope things will be quieter at work, so I can
think this through with the proper detail needed

On 4/5/06, John Wilson <tug@...> wrote:
>
> On 23 Mar 2006, at 15:42, Jeremy Rayner wrote:
>
> > It's a -1 from me, but I haven't had time to formulate my reasoning in
> > a good email yet
>
>
> Jez,
>
> are you able to formulate your objections to this yet?
>
>
> John Wilson
> The Wilson Partnership
> web http://www.wilson.co.uk
> blog http://eek.ook.org
>
>
>

--
Groovy JSR Co-Spec Lead
http://javanicus.com/blog2

JSR: brain storming

Re: Proposal to Improve <at> Property Syntax

Jeremy,

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.

Graeme

On 4/5/06, Jeremy Rayner <jeremy.rayner@...> wrote:
> After this week is over I hope things will be quieter at work, so I can
> think this through with the proper detail needed
>
> On 4/5/06, John Wilson <tug@...> wrote:
> >
> > On 23 Mar 2006, at 15:42, Jeremy Rayner wrote:
> >
> > > It's a -1 from me, but I haven't had time to formulate my reasoning in
> > > a good email yet
> >
> >
> > Jez,
> >
> > are you able to formulate your objections to this yet?
> >
> >
> > John Wilson
> > The Wilson Partnership
> > web http://www.wilson.co.uk
> > blog http://eek.ook.org
> >
> >
> >
>
>
> --
> Groovy JSR Co-Spec Lead
> http://javanicus.com/blog2
>

Re: Proposal to Improve <at> Property Syntax

On Mon, 2006-04-17 at 13:24 +0100, 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.

There is a difference between agreeing with a proposal.  I still quite
like  <at> Property so don't positively agree with the change but I am
prepared to accept the majority decision which currently is to go with
John's proposal.

--

-- 
Russel.
====================================================
Dr Russel Winder                +44 20 7585 2200
41 Buckmaster Road              +44 7770 465 077
London SW11 1EN, UK             russel@...

Re: Proposal to Improve <at> Property Syntax

Graeme Rocher wrote:
> Jeremy,
> 
> 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

bye blackdrag

Re: Proposal to Improve <at> Property Syntax

On 4/17/06, Jochen Theodorou <blackdrag@...> wrote:
> Graeme Rocher wrote:
> > Jeremy,
> >
> > 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

Graeme

>
> bye blackdrag
>
>
>

Re: Proposal to Improve <at> Property Syntax

Let's implement it, there's been enough wait on that change.

On 4/18/06, Graeme Rocher <graemerocher@...> wrote:
> [...]
> Fair enough :) but there has yet to be a conclusive argument against..
> and we keep waiting

--
Guillaume Laforge
Groovy Project Manager
http://glaforge.free.fr/blog/groovy

Re: Proposal to Improve <at> Property Syntax

Graeme Rocher wrote:
> On 4/17/06, Jochen Theodorou <blackdrag@...> wrote:
> 
>>Graeme Rocher wrote:
>>
>>>Jeremy,
>>>
>>>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.

A matter of taste, just as I said.

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

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:
> >>
> >>>Jeremy,
> >>>
> >>>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.
Agreed.

Graeme

>
> bye blackdrag
>