removing "=" from places with boolean conditions

[Jochen Theodorou]

Hi,

I think we should avoid having code like

if (foo=2){ bar() }

I know this is valid in Java as long the assigned value is a boolean,
but in groovy we evaluate more than just booleans. So removing "=" and
it's friedns "+=","-=" etc. would be good to avoid the well known error
from C. That feature is so rarely used even in Java, I don't think it is
a loss.

And it makes programming more easy. The change to the grammar is really
small, it would affect. if and while, if we ever support the classic
for-loop, then there too. we can also talk about if it does make sense
in a synchronized statement. We could also remove it from arguemnts,
foo(x=4) wouldn't be allowed then. Then there is also "use", "switch"
and "with"... "with" is still in the grammar.. hmm

I think it is a good idea to remove it from there.

thoughts?

bye blackdrag

--
Jochen Theodorou
Groovy Tech Lead

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[graemer]

I must say I've been caught by this trap 2 or 3 times by accidently
missing out on the extra = sign. I personally wouldn't miss it, are
there any wider implications that havn't been thought about?

Graeme

On 6/16/06, Jochen Theodorou <blackdrag@...> wrote:

> Hi,
>
> I think we should avoid having code like
>
> if (foo=2){ bar() }
>
> I know this is valid in Java as long the assigned value is a boolean,
> but in groovy we evaluate more than just booleans. So removing "=" and
> it's friedns "+=","-=" etc. would be good to avoid the well known error
> from C. That feature is so rarely used even in Java, I don't think it is
> a loss.
>
> And it makes programming more easy. The change to the grammar is really
> small, it would affect. if and while, if we ever support the classic
> for-loop, then there too. we can also talk about if it does make sense
> in a synchronized statement. We could also remove it from arguemnts,
> foo(x=4) wouldn't be allowed then. Then there is also "use", "switch"
> and "with"... "with" is still in the grammar.. hmm
>
> I think it is a good idea to remove it from there.
>
> thoughts?
>
> bye blackdrag
>
> --
> Jochen Theodorou
> Groovy Tech Lead
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[tugwilson]

On 16 Jun 2006, at 15:03, Jochen Theodorou wrote:

> Hi,
>
> I think we should avoid having code like
>
> if (foo=2){ bar() }
>
> I know this is valid in Java as long the assigned value is a  
> boolean, but in groovy we evaluate more than just booleans. So  
> removing "=" and it's friedns "+=","-=" etc. would be good to avoid  
> the well known error from C. That feature is so rarely used even in  
> Java, I don't think it is a loss.
>
> And it makes programming more easy. The change to the grammar is  
> really small, it would affect. if and while, if we ever support the  
> classic for-loop, then there too. we can also talk about if it does  
> make sense in a synchronized statement. We could also remove it  
> from arguemnts, foo(x=4) wouldn't be allowed then. Then there is  
> also "use", "switch" and "with"... "with" is still in the grammar..  
> hmm
>
> I think it is a good idea to remove it from there.
>
> thoughts?

no objection.

I presume that

if ((a = b)) ...

would still be legal?

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



---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

John Wilson schrieb:
>
[...]
> I presume that
>
> if ((a = b)) ...
>
> would still be legal?

hmm.. right my change doesn't cover that. But I think I could. You want
to keep that?

bye blackdrag

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Dierk König]

I would like to have a bit of time to consider the impact.

First, this also applies to 'assert' and any method call with
a boolean argument. Another related case is using (foo=2)
inside arbitrary expression, where it is really ugly.

Second, the most common errors can be avoided by placing the
literal to the left of the equation
 if (2 == foo) ...

Third, there are common use cases with 'while'

 while (c = in.read()) { process c }

which is cool in Groovy because you can do things like

 while (obj = in.readObject()) { obj.doSomething()}

Fourth, when porting Java code to Groovy things can get
more complicated, since that construct is often-used in Java.
It can be found throughout the JDK.

cheers
Mittie

P.S.: For _after_ 1.0 I could imagine making the () after
if, while, for, switch, and catch, optional when there is
a trailing {block}.

> -----Original Message-----
> From: Jochen Theodorou [mailto:blackdrag@...]
> Sent: Freitag, 16. Juni 2006 16:04
> To: jsr@...
> Subject: [groovy-jsr] removing "=" from places with boolean conditions
>
>
> Hi,
>
> I think we should avoid having code like
>
> if (foo=2){ bar() }
>
> I know this is valid in Java as long the assigned value is a boolean,
> but in groovy we evaluate more than just booleans. So removing "=" and
> it's friedns "+=","-=" etc. would be good to avoid the well known error
> from C. That feature is so rarely used even in Java, I don't think it is
> a loss.
>
> And it makes programming more easy. The change to the grammar is really
> small, it would affect. if and while, if we ever support the classic
> for-loop, then there too. we can also talk about if it does make sense
> in a synchronized statement. We could also remove it from arguemnts,
> foo(x=4) wouldn't be allowed then. Then there is also "use", "switch"
> and "with"... "with" is still in the grammar.. hmm
>
> I think it is a good idea to remove it from there.
>
> thoughts?
>
> bye blackdrag
>
> --
> Jochen Theodorou
> Groovy Tech Lead
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Dierk Koenig schrieb:
> I would like to have a bit of time to consider the impact.
>
> First, this also applies to 'assert' and any method call with
> a boolean argument.

if I do it for merhod arguments, then it applies to assert as well, yes.
But why is that a problem?

> Another related case is using (foo=2)
> inside arbitrary expression, where it is really ugly.

yes, that's why I think I can life without it ;)

> Second, the most common errors can be avoided by placing the
> literal to the left of the equation
>  if (2 == foo) ...

not if both sides are variables and it doesn't read well.

> Third, there are common use cases with 'while'
>
>  while (c = in.read()) { process c }
>
> which is cool in Groovy because you can do things like
>
>  while (obj = in.readObject()) { obj.doSomething()}

yes... but we need that? I really hate such code, it doesn't read well.

> Fourth, when porting Java code to Groovy things can get
> more complicated, since that construct is often-used in Java.
> It can be found throughout the JDK.

I never use it. Of course I know other people do, but I really don't
like that construct. Defining a generic read method on Streams would be
more helpfull here. which remembers me that GStrings as method names are
not yet implemented.. I have to change that.. any if that where possible
we could do:

def readLoop(stream,type,action){
   while (true) {
     def val = stream."read$type"()
     if (!val) break
     action(val)
   }
}

readLoop(in,"Object") { obj ->
   obj.doSomething()
}

when defined on the stream itself:

in.readLoop("Object") { obj ->
   obj.doSomething()
}

instead of text we could also give the class. The Java version would use
the MetaClass to make the call or use a if-else cascade. Nothing that
isn't doable.

[...]
> P.S.: For _after_ 1.0 I could imagine making the () after
> if, while, for, switch, and catch, optional when there is
> a trailing {block}.

maybe, yes

bye blackdrag

--
Jochen Theodorou
Groovy Tech Lead

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Dierk König]

> > I would like to have a bit of time to consider the impact.
> >
> > First, this also applies to 'assert' and any method call with
> > a boolean argument.
>
> if I do it for merhod arguments, then it applies to assert as well, yes.
> But why is that a problem?

It's not a problem as such. I just wanted to show that it's not
only the 'if' that is concerned.

Another point is that assignments evaluate to the assigned value.
Should that also be changed?

def x = 1
def foo(){ x = 2 }
println foo()
if(foo()) ...

> > Another related case is using (foo=2)
> > inside arbitrary expression, where it is really ugly.
>
> yes, that's why I think I can life without it ;)

:-)

> > Second, the most common errors can be avoided by placing the
> > literal to the left of the equation
> >  if (2 == foo) ...
>
> not if both sides are variables and it doesn't read well.

Well, a matter of taste, I'd say.
It's not the usual way but I like it because it since the sequence
of operands reminds me on JUnit's assert methods: putting the
expectation first.

Of course, this works only if one of the operands is a non-lvalue
(literal or method call).

> > Third, there are common use cases with 'while'
> >
> >  while (c = in.read()) { process c }
> >
> > which is cool in Groovy because you can do things like
> >
> >  while (obj = in.readObject()) { obj.doSomething()}
>
> yes... but we need that? I really hate such code, it doesn't read well.

Well, I would not argue in favor of the above examples either
but disallowing everything that we don't "like" to see as Groovy
code brings us in the tricky position of deciding about beauty.

ATM I feel we should allow programmers to start programming Groovy
with what they know.

> > Fourth, when porting Java code to Groovy things can get
> > more complicated, since that construct is often-used in Java.
> > It can be found throughout the JDK.
>
> I never use it. Of course I know other people do, but I really don't
> like that construct.

Of course it has a smell: it does a boolean test with the side-effect
of an assignment. But lots of readXXX methods have an analogous
smell: returning a value while side-effecting the underlying
Stream/Reader. No wonder they are used in combination so often ;-)

We cannot prevent people from writing code that we personally
don't like anyway. (I personally don't like ?: very much, but so what?)

cheers
Mittie

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Dierk Koenig schrieb:
>>> I would like to have a bit of time to consider the impact.
>>>
>>> First, this also applies to 'assert' and any method call with
>>> a boolean argument.
>> if I do it for merhod arguments, then it applies to assert as well, yes.
>> But why is that a problem?
>
> It's not a problem as such. I just wanted to show that it's not
> only the 'if' that is concerned.

ah! No, I can limit it for each construct seperatly, but if I limit it
for method parameters, then I limit it for assert too

> Another point is that assignments evaluate to the assigned value.
> Should that also be changed?
>
> def x = 1
> def foo(){ x = 2 }
> println foo()
> if(foo()) ...

I think the problem there is not as big as with the "if". I don't know
about you, but I wouldn't read here x==2 by default because the keyword
"if" is not there to trigger the fast code scan mode ;)

[...]
> We cannot prevent people from writing code that we personally
> don't like anyway. (I personally don't like ?: very much, but so what?)

sure, I really don't want to do that. People should be able to decide to
build their own traps if they really want to. But I thik at last for the
"if", we can avoid that without loosing anything. the decision is maybe
more for politics here than for anything else.

bye blackdrag

--
Jochen Theodorou
Groovy Tech Lead

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email