jastrachan | 15 Feb 19:37 2005

Re: Re: static versus dynamic typing policy

On 15 Feb 2005, at 18:25, Chris Poirier wrote:
> Hi James,
> I'm off this JSR, so feel free to ignore me, too.  Come to think of it,
> I'm not sure that would be any different if I were still on the JSR.
> Hmmm.
>>>  A field inside of a class is a field, period, that may have
>>> property-access bolted onto it.
>>> Both optional parenthesis and properties access were added to Groovy
>>> _to make scripting easier_.  Again, we do not need to invoke MOP or
>>> unified access or Scheme.  They're just ways to make scripting 
>>> easier.
>> There's still a MOP underpinning it even if you don't wanna think 
>> about
>> it that way.
> To call even Reflection a MOP is akin to calling a crack in the 
> pavement
> a "fault line".  While technically correct, it's not a very useful
> correlation to make.

Its not reflection. MetaClass is a MOP; if you wanna think of it as 
reflection, please go right ahead - but in my mind its always been a 

> Changing Groovy to remove the syntactic differences between method 
> calls
> and field access is not a minor change.  It is one of those policies
> that fundamentally defines a language.  It is neither good nor bad --
> only appropriate or inappropriate.  For what Groovy has been (a
> scripting language for use by Java programmers) it is wholly
> inappropriate, for the reasons noted by Guillaume, Russell, and others.

Hmm; when resolving any name, we use MetaClass.getProperty() right now, 
today. We can make changes to how that method works without much work.

> FActually it handles pretty much all of the Groovy AST already - its
>> just the Antlr grammar has a few glitches that need fixing. FWIW all 
>> of
>> the classic groovy test cases are parsing now with the new groovy 
>> Antlr
>> parser apart from about 6-7 bugs...
> Just a question for accuracy's sake, here: how many of those "now
> working" test cases were rewritten to avoid the gotchas in the new
> grammar?

All the changes are on the wiki page; the biggest gotcha were tests like

class Foo {

    aMethod() {

which now require a type or def to avoid ambiguity - most of the rest 
just worked

> How many of them are longer than 10 lines of actual test code

Dunno - try 'wc' :)

> and how many of them do actually useful things?

They all do stuff, I'll leave the reader to decide how useful :)

>>> With these pieces still not working, this is another proposal that
>>> adds more changes and is demonstrably much more difficult than the
>>> obvious simple fixes.  John, this is your proposal so I assume you
>>> know: how long will this proposal take to implement?
>> Just because the Antlr grammar today has a few bugs doesn't mean we
>> should stop discussing things - I don't follow your reasoning here.
> To my reading, the only person today who has suggested curtailing
> discussion of these changes is John Rose, who implied with his language
> that the decision has already been made, and the rest of us should just
> deal.

Not at all

> Mike stated a contrary opinion to John, as did Russell and Guillaume.
> Why did you reply to him before the others?

Time - I'm snowed under today, am just back from vacation & very behind 
on mail... I'll try reply to as many mails recently - and apologies for 
diving into the end of a conversation before reading & responding to 
every post...

>  To the casual observer, it
> might appear that you hoped to malign the position by attacking the
> least popular supporter.

No - I was just trying to ensure we don't try and shut anyone up & keep 

> James, it is clear you don't like Mike.

Not at all

>  I'll even admit that you have
> reason.  But you aren't doing either yourself or your community any
> service by just ignoring his points on that basis.

I'm not ignoring his points - they are very valid concerns -  I was 
trying (and obviously failing miserably) to say, lets keep debating 
this issue and make the right decision and not use the current status 
of the Antlr grammar or Groovy AST mappings as excuses for stopping the