# Between operator

24 replies [Last post]
yishai
Offline
Joined: 2003-11-16

Something to evaluate that a primative is between two values. Such as:

[pre]

if (1 < var < 10) {
System.out.println("var is greater than one and less than ten.");
}

[/pre]

wingetr
Offline
Joined: 2004-01-19

> Let's also add a feature that allows me to check whether a number is positive when we're at it.

Funny you should mention that - there is a new method in Math that returns the sign (-1,0,1) of a number.

kcpeppe
Offline
Joined: 2003-06-15

> I think you just define (1 > (1 > What are you worried about, exactly?

1 < n < 10

Humm strange grammer.. certianly would break an LR(1) parser. Is that how javac is currently implemented?

Consider it as a series of message sends...

1 < n < 10

1 < n evaluates to a boolean, lets pick true...

true < 10

and that doesn't seem to work either.

How would you propose to adjust the parser?

applebanana8
Offline
Joined: 2004-06-16

> 1 < n < 10
>
> Humm strange grammer.. certianly would break an LR(1)
> parser. Is that how javac is currently implemented?

First, you should not worry about implementation, if you don't know it :-)

Second, I guess it's not so difficult to parse it even with a recursive descent parser. Consider it as

E < E [< E]

with [] denoting optional tokens. Then, parsing an expression, a less-than and another expression, you can decide based on the next token whether you have another "<" (the between operator) or continue with "normal" parsing.

Then, since it is syntactic sugar, you just change it at parse time to (E1 < E2 && E2 < E3) and there you go... from then on, noone has to know about our little trick (all the following phases remain unchanged).

> Consider it as a series of message sends...
>
> 1 < n < 10
>
> 1 < n evaluates to a boolean, lets pick true...
>
> true < 10
>
> and that doesn't seem to work either.

it works if object "true" has a method "<", a bit like Smalltalk does it. But anyway, I think the syntactic sugar approach is much easier.

bye

kcpeppe
Offline
Joined: 2003-06-15

Ok, so 1 < X < 10 goes to 1 < X && X < 10....

try
1 < Y < X < 10
-> 1 < Y && ( Y < X < 10)
-> 1 < Y && Y < X && X < 10

A bit funky but why not

> > Consider it as a series of message sends...
> >
> > 1 < n < 10
> >
> > 1 < n evaluates to a boolean, lets pick true...
> >
> > true < 10
> >
> > and that doesn't seem to work either.
>
> it works if object "true" has a method "<", a bit
> like Smalltalk does it.

lets see.. true < 1

Sorry, still doesn't work ;)

yishai
Offline
Joined: 2003-11-16

> try
> 1 < Y < X < 10

No, I wouldn't want that. Too confusing to read, then I have to know how you parse it for that to make sense. 3 arguments is the limit for me.

> lets see.. true < 1
>
> Sorry, still doesn't work ;)

I think he meant a subclass of true which implements the < to care about the type of X.

Anyway, that is why I don't like operator overloading. It makes things not make sense anymore.

monika_krug
Offline
Joined: 2004-10-14

> The motivation for me is the need to redo the same
> thing over and over. Even when it is a small utility
> method, I start to ask why the language doesn't do it
> for me. It isn't always possible or easy to move
> around utility classes from project to project, and
> the overhead of starting a new method on a utility
> class can be more than just recoding it again.

Then maybe this method should be added to java.lang.Number.

Monika.

yishai
Offline
Joined: 2003-11-16

> Then maybe this method should be added to
> java.lang.Number.

I think that would get too out of hand to be worth it. With the operators, you can do things like:

1 <= rs.getInt(1) < 10

1 < rs.getInt(1) <= 10

1 <= rs.getInt(1) <= 10

10 > rs.getInt(1) > 1

etc.

Not to mention variations on doubles and the like.

Doing all of that in utility methods with names you can remember becomes impossible. On your own project, you can limit the utility methods to the cases you actually use. On the Java API, they have to be more flexible.

monika_krug
Offline
Joined: 2004-10-14

The utility method only needs to exist for double, everything else from byte to float would be automatically casted.

With what you write now - did you not mean to introduce the keyword "between", but you literally want "1 < x < 10" to work?

This does not have the disadvantage of a "between" keyword that would break existing code.

It would make a significant change in evaluating expressions. 1

But it is probably possible to be implemented as a special case.

Monika.

yishai
Offline
Joined: 2003-11-16

> The utility method only needs to exist for double,
> everything else from byte to float would be
> automatically casted.

I don't know that with the impressison of double that that is a good idea, but I'll take your word for it. I don't know enough about how imprecise doubles are.

>
> With what you write now - did you not mean to
> introduce the keyword "between", but you literally
> want "1 < x < 10" to work?

Yes.

The utility method breaks down where < and <= both have to be taken into consideration, on both sides of the comparison. You can do it in a utility method (you can do most anything the language currently allows for in a utility method) but it would make the code clunky and hard to read:

[pre]
import java.util.SomeUtility;
...
if (between(1,var,10,DOUBLE_SIDED_LESS_THAN))
...
[/pre]

No thanks. I'll take the &&

monika_krug
Offline
Joined: 2004-10-14

> The cost/value is definitely something for Sun to
> decide. The value for me would be more in the case
> where getting x was an expensive method call (from a
> ResultSet, say). You have to cache the method call
> yourself, which always seems clunky.
>
> I could be wrong, but the only cost I see in this is
> the effort of implementing it, and the burden on IDE
> coders to parse it. There would need not be any
> JVM/bytecode changes, as the compiler could handle
> the mess.

But adding a new keyword breaks all existing code that uses "between" as a variable or method name!

Monika.

regexguy
Offline
Joined: 2003-06-20

But the suggestion was not to add a new keyword, the suggestion was to make

1 < n < 10

a shorthand for

(1 < n && n < 10)

smbell
Offline
Joined: 2003-10-12

I'm simply tired of whiny programmers who complain about having to type a few extra key strokes. All this syntactic sugar crap is pointless outside of saving our poor little fingers from some work. The question shouldn't be how can we do this, but why should we do this. Does this new thing give us the ability to do something we were previously unable, or greatly simplify a common task.

I don't think the saving of about 7-8 keystrokes is something to be thought of as a great simplification.

scott_sauyet
Offline
Joined: 2004-08-25

> I don't think the saving of about 7-8 keystrokes is
> something to be thought of as a great simplification.

I don't think the OP was claiming great simplification. This is one of the little things. That doesn't mean it's worthless. There are two questions for developers:

1. Does it make reading and writing code easier?

2. Does it make [i]learning[/i] to read and write code harder?

To me the answers are 1-yes, 2-no. This means that to me this is a a worthwhile addition to the language. It is far from urgent, but it is useful.

The implementation issues are separate, and I don't know enough about Java parsers to know how difficult this would be to add. Such concerns could certainly scuttle the proposal, and no one would shed a tear. But if it would be easy to add to parsers, if most tools could easily be extended to support it, I don't see any objection.

Of course this is based on my feeling that this change would make it somewhat easier to read and write code and wouldn't make it harder to learn to read and write code. If there are serious debates on those points, it's a different issue.

patrikbeno
Offline
Joined: 2004-10-11

-1

1) i think this would break the way expressions are evaluated, operator associativeness etc
2) it is not worth introducing new keyword even if this would be a solution
3) it would be first operator that takes three arguments (var, min, max) which introduces complexity to current expression evaluation scheme

Thining about it, I guess it would be feasible but not worth effort

regexguy
Offline
Joined: 2003-06-20

I think you just define (1

patrikbeno
Offline
Joined: 2004-10-11

1 < var evaluates to boolean

if 1 < var < 10 expands to (1 < var && var < 10), it complicates things because it is already defined that (1

How far can we go like this?

1 < var < 10 < x < 100 ???

What is, then?

1 < var && var < 10 && 10 < x && x < 100

You see, single operand (10) is used in multiple expressiions. You don't have simple parse tree, you have cross references...

This proposal breaks the way Jvaa operators work.
Feasible, I guess, but too complicated compared to benefit it promises.

monika_krug
Offline
Joined: 2004-10-14

-1

Even though this is a nice operator that would abbreviate code like 1 < x && x < 10, it is certainly not worth the effort and the trouble adding an operator to Java.

Monika.

yishai
Offline
Joined: 2003-11-16

> -1
>
> Even though this is a nice operator that would
> abbreviate code like 1 < x && x < 10, it is certainly
> not worth the effort and the trouble adding an
> operator to Java.
>
> Monika.

The cost/value is definitely something for Sun to decide. The value for me would be more in the case where getting x was an expensive method call (from a ResultSet, say). You have to cache the method call yourself, which always seems clunky.

I could be wrong, but the only cost I see in this is the effort of implementing it, and the burden on IDE coders to parse it. There would need not be any JVM/bytecode changes, as the compiler could handle the mess.

tsinger
Offline
Joined: 2003-06-10

I'm always surprised to see people asking for language changes, where simple methods do the trick very nice. This piece of code should illustrate our approach:

[code]public static boolean isInOpenInterval(long lowerBorder, long value, long upperBorder) {
return lowerBorder < value && value < upperBorder;
}

...
if (isInOpenInterval(1, x, 10)) {
// do something
}
...[/code]

Tom

yishai
Offline
Joined: 2003-11-16

> I'm always surprised to see people asking for
> language changes, where simple methods do the trick
> very nice.

The motivation for me is the need to redo the same thing over and over. Even when it is a small utility method, I start to ask why the language doesn't do it for me. It isn't always possible or easy to move around utility classes from project to project, and the overhead of starting a new method on a utility class can be more than just recoding it again.

regexguy
Offline
Joined: 2003-06-20

I understand the reluctance to add new features to a language. It often makes it more complex to learn and write.

But I think this is an exception. This is such an intuitively obvious thing to read, and I have many times, over the years, wished I could write this very thing whether I was programming java, C++, f77, ...

What I like about it is that it's more natural to write things that way.

And it strikes me that the cost is all on the guys writing JRE's, and even there I doubt that it's heavy.

jwenting
Offline
Joined: 2003-12-02

-1

> I understand the reluctance to add new features to a
> language. It often makes it more complex to learn
> and write.
>
fully agreed. Language feature bloat makes for impossible to learn languages...

> But I think this is an exception. This is such an
> intuitively obvious thing to read, and I have many
> times, over the years, wished I could write this very
> thing whether I was programming java, C++, f77, ...
>
And so everyone has his or her own pet thing they want added.
When you start down the road of adding everything someone thinks an obvious addition soon you'll get the thing you don't want.
Let's also add a feature that allows me to check whether a number is positive when we're at it.
Just doing if (x>0){ ... } is so much typing, let's create a keyword ifpos and do away with the parenthesis so I can type ifpos x { ... } similar to the use of instanceof.
And while we're at it, add ifneg as well as a keyword.
And isnull.
All things that are intuitive and everyone uses them all the time...

No, I don't think such things should be added.

> And it strikes me that the cost is all on the guys
> writing JRE's, and even there I doubt that it's heavy.

no it's not. It's on the million+ Java programmers who will have to use yet more new syntax...

yishai
Offline
Joined: 2003-11-16

> And so everyone has his or her own pet thing they
> someone thinks an obvious addition soon you'll get
> the thing you don't want.
> Let's also add a feature that allows me to check
> whether a number is positive when we're at it.
> Just doing if (x>0){ ... } is so much typing, let's
> create a keyword ifpos and do away with the
> parenthesis so I can type ifpos x { ... } similar to
> the use of instanceof.
> And while we're at it, add ifneg as well as a
> keyword.
> And isnull.
> All things that are intuitive and everyone uses them
> all the time...

I think there is a difference between kewords and operators. Operators have limitations of growth. And once you know what < and > stand for 1 < i < 10 is so obvious it doesn't need to be explained.

If you want to object to operators, I think the for each implementation is much more subject to that objection. It is much harder to understand (or even describe) using the : operator, and easily doable yourself, etc. etc.

Also, I don't think saying that everybody has their pet thing they want added is an argument for never having an additional keyword or operator. I agree that every suggestion shouldn't be taken, but if there is enough demand for it, Java should be proactive about it.

The current solution that Sun seems to have fallen into is to wait on new language features until C# announces them first. I don't think that is a good way to keep Java as the leading language.

If I am in the minority about this suggestion, no problem. No way to find out without suggesting it.

regexguy
Offline
Joined: 2003-06-20

+1