headers
Mark Chu-Carroll | 3 Aug 2004 02:00
Picon

Re: use special syntax for method pointers?

I know this is jumping into the conversation pretty late, but I figure
better late than never...

On Wed, 14 Jul 2004 17:08:48 +0100, John Wilson <tug@...> wrote:
> 
> On 14 Jul 2004, at 16:05, jastrachan@... wrote:
> 
> > On 14 Jul 2004, at 12:58, Wilson, Greg wrote:
> >> Hi James.  I vote for solving the problem by requiring the
> >> parentheses, even when there are no arguments (if for no
> >> other reason than the Principle of Least Surprise).
> >
> > Whether we use mandatory or optional parenthesis isn't really the
> > point of this thread :). I think I explained it badly, I'll try once
> > more...
> >
> >
> 
> [snip]
> 
> > Does that help clear it up? Whether we use mandatory parenthesis on
> > methods with no arguments or not, we still have this issue I think.
> > The issue really is about confusion between method pointers and bean
> > properties and making the syntax to 'create a reference to an objects
> > method'  should maybe be more explicit to avoid confusion? In C/C++
> > the & is used to create a pointer to something hence my thinking of
> >
> > object.&methodName
> >
> > though we could always have some new method
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wilson, Greg | 3 Aug 2004 22:00
Picon
Favicon

RE: [groovy-dev] another "global" solution on the table

On Thu, 29 Jul 2004 17:04:49 -0700, Net Bean <netbean@...> wrote
(in the 'dev' list):

> > This is all "bass-ackwards", it doesn't seem like
> > we've defined what we want for variable scoping (wrt 
> > globals) and how 
> > we want it to look like. We need to do that before we 
> > figure out how 
> > it can be implemented in the backend / interpreter / compiler.

+1 --- and not just for globals.  It seems like some pretty big
features are being added without discussion/agreement on what the
end point is:

1. Is Groovy going to be a strict superset of Java whose compelling
   feature is ease of use?  (It appears not --- a lot of Java code
   already won't work as Groovy.)

2. Is Groovy going to be a syntactically-distinct language whose
   compelling features are ease of use and modern features?  This
   seems to be the current plan, but as more (modern or not) features
   are added, learnability, and ease of use for average programmers,
   is reduced.

Related questions:

3. How do we tell when we're done?  When no-one on the 'jsr' or 'dev'
   list can convince a majority of her/his fellows to add another
   feature?  Or is there some other close-off criterion?
(Continue reading)

Permalink | Reply | 0 comments |

Gmane