methods with "short"-typed arguments.

  • Thread starter Andreas Leitgeb
  • Start date
O

ojacobson

Seriously? You explicitly list 65,536 literal short values? You've
actually done this?

Check your sarcasm meter. If it hasn't gone off yet, it will in a
second:

Of course, you wouldn't write that class by hand; you'd obviously
generate it at build time.

-o, tongue firmly in cheek
 
A

Andreas Leitgeb

Lew said:
Seriously?
Not entirely seriously, but now I'm curious about the implications...
If some attribute is "trademarked", it may not have its usual meaning :)
You explicitly list 65,536 literal short values? You've
actually done this?

Even 32768 constant fields per class are too many, since
each consumes two slots in the constant pool: name and value,
plus there are some more things that also must fit in there.

Out of curiosity, I created (automatically, from a small tcl script)
such a class with 32760 (8 less) constants. It then was compileable.

I then created a small class User, that did the "import static",
and it worked (of course), even though it took considerably more
time to compile (3.7secs) than without that crap (1.24secs).

So, it definitely doesn't pay for the full short-range.

Doing it for the byte-range and perhaps for a sufficiently
small group of shorts, that may (due to domain-specifics
of some particular problem-space) be very frequently used
as immediates to methods taking shorts, ...
may even be feasible.
I am just shaking my head in incredulity.
:)

holder.foo( (short) 8191 );
Depends on how many such lines are at stake...
I find "(short)" visually quite disturbing, so probably
my critical number would be lower than yours.
 
L

Lew

Check your sarcasm meter.  If it hasn't gone off yet, it will in a
second:

Of course, you wouldn't write that class by hand; you'd obviously
generate it at build time.

You obviously wouldn't generate it at all.
 
L

Lew

Andreas said:
Depends on how many such lines are at stake...
I find "(short)" visually quite disturbing, so probably
my critical number would be lower than yours.

That's a good engineering basis for that decision, there.

Some people find all sorts of idioms "visually quite disturbing" that
are fundamental to Java and its way of doing things. They provided a
way to do what you want - or say you want - to deliver a 'short'-type
argument to a method. The fact that it doesn't fit someone's esthetic
is unfortunate, but not an indictment of the Java language. While one
person is upset that there are too many '(short)' casts in their code,
another person is using them to write effective, maintainable, type-
safe code.
 
A

Andreas Leitgeb

Lew said:
Some people find all sorts of idioms "visually quite disturbing" that
are fundamental to Java and its way of doing things.

And *some* of the previously "visually quite disturbing" warts already
got treated: namely by the new "for"-loops, generics, varargs, enums, ...

I admit, that those warts were much worse than that one currently dicussed
here.
 
T

Tom Anderson

PS: to be honest, a postfix for byte/short literals would be mostly
syntactic sugar for the cast. I think it's good sugar, others may
disagree.

I've been reading about about the Javascript (well, ECMAScript) standards
process recently, and they have a very interesting take on syntactic
sugar: they like it. Or rather, they see no problem at all with
introducing new syntax as long as it's only sugar for existing syntax.
What they don't like is any change which alters the underlying semantics
of the language.

This runs against conventional language design thinking, where syntactic
sugar is severely frowned upon, being seen as an unnecessary frippery
which doesn't add anything to the language.

The basis for this is that supporting syntactic sugar only involves some
(probably quite simple) extensions to the parser, and thus is an easy and
safe way of improving the programming experience, whereas semantic changes
require deeper changes to implementations, and risk introducing unforseen
complications in the way they work in practice and interact with other
language features.

I'm not sure i fully agree with this aesthetic, but i found it rather
interesting.

tom
 
A

Arne Vajhøj

Andreas said:
probably a bad example, because if you stored a literal in a
static final then it does have some very explicit type.
static final short ANSWER = 42;

Ooops.

You are of course right. It is literals in the call itself that will
cause this behavior not constants that are types in Java.
If we're leaving static finals aside now, and use literals, then
it would be possible, that where previously the "int"-variant of
a method was called, that then a "byte"-variant could be called,
or in some multi-arguments cases the compiler could then error out
complaining about ambiguity, as it already does in some class-
hierarchy-related situations.

Having explicit byte- and short- literal postfixes would indeed
prevent a change in behaviour of old code. I think I start to like
that idea, as it's the least even possibly painful thing.

PS: to be honest, a postfix for byte/short literals would be mostly
syntactic sugar for the cast. I think it's good sugar, others may
disagree.

As I said - I like it !

Arne
 
A

Arne Vajhøj

Lew said:
You're not supposed to put magic numbers in code anyway. Declare static
final variables to hold your constants, then you get the rest of your wish.

static final byte MAGIC_NUMBER = 23;
...

invoke( MAGIC_NUMBER );

There is a difference between what the rules of the language and
good style.

Arne
 
A

Andreas Leitgeb

Arne Vajhøj said:
There is a difference between what the rules of the language and
good style.

Despite my previous answer (taking that idea quite beyond extreme),
Lew does have a point here.

The frequency of short/byte-literals in normal Java code is rather
low, and probably most of such literals really have a meaning that
leads to an apt name for a static final field to store it in.

The situation that triggered this thread was probably less common:
A small testsuite(*), calling methods of some object with carefully
chosen test-values. Some of these values (those that where used
more than once) were already stored in static finals before I even
started the thread, but other values appeared each only in one of
a whole lot of lines, and the thought of assigning *them* to constants
led to thinking about that "Literals" class :)

*: I haven't yet entered the world of JUnit...
 
A

Andreas Leitgeb

Andreas Leitgeb said:
*: I haven't yet entered the world of JUnit...

And in the context of visual clutter, switching from
Java to XML (junit) is probably like jumping out of
the frying pan right into the fire.
 
A

Arne Vajhøj

Andreas said:
And in the context of visual clutter, switching from
Java to XML (junit) is probably like jumping out of
the frying pan right into the fire.

?

Where did the XML come into the picture ?

Arne
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,898
Latest member
BlairH7607

Latest Threads

Top