Invocations (was: How to implement tab order?)

S

Stefan Ram

Ian Wilson said:
this.add( titleLabel,
new GBC( 0,0, 2,1, 0.0,0.0, GBC.WEST, GBC.NONE, 5,5,0,5, 0,0 ));

For readability, one would actually like to have keyword
arguments as in Smalltalk, SQL or VBA. As in

new GridBagConstraints
( gridx := 0, gridy := 0, gridwidth := 2, gridheight := 1, ... );

In Java one could use either

{ final int gridx = 0; final int gridy = 0;
final int gridwidth = 2; final int gridheight = 1; ...
new GridBagConstraints( gridx, gridy, gridwidth, gridheight, ... ); }

or

new GridBagConstraints
( /* gridx */ 0, /* gridy */ 0,
/* gridwidth */ 2, /* gridheight */ 1, ... );

Newsgroups: comp.lang.java.gui,comp.lang.java.programmer
Followup-To: comp.lang.java.programmer
 
T

Thomas Hawtin

Stefan said:
For readability, one would actually like to have keyword
arguments as in Smalltalk, SQL or VBA. As in

Does SQL have keyword arguments?
In Java one could use either

Or:

GridBagConstraints cons = new GridBagConstraints() {{ // Evil...
gridx = 0; gridy = 0; gridwidth = 2; gridheight = 1; ...
}};

However, your colleagues might want to have words with you if they saw
that...

From 1.5 the constants can be imported with import static. My
preference is to subclass GridBagConstraints with a class that is more
suited as a builder. Also replace the use of int constants with enums. So:

import mypackage.layout.GridBag.Constraints;
import static mypackage.layout.GridBag.Constraints.Anchor.*;
import static mypackage.layout.GridBag.Constraints.Fill.*;
....
Constraints cons = new Constraints()
.gridLocation(0, 0)
.gridSize(2, 1)
.anchor(WEST)
.fill(HORIZONTAL)
.insets(5, 5, 0, 5);
....

Tom Hawtin
 
T

Thomas Hawtin

Stefan said:
The SQL-syntax based notation could look like:

SELECT * FROM( SELECT NEW FROM GRID_BAG_CONSTRAINTS )

Just "select * from grid_bag_constraints" where grid_bag_constraints is
a domain, I think.
WHERE GRIDX = 0
AND GRIDY = 0
AND GRIDWIDTH = 2
AND GRIDHEIGHT = 1
AND ... ;

AND ... AND ... AND ...

You'd have to specify every field, otherwise you would end up with a set
of all possible constraints meeting the constraints, rather than using
sensible defaults.

Or just:

select
0 as gridx, 0 as gridy, 2 as gridwidth, 1 as gridheight, ...
from dual

Tom Hawtin
 
S

Stefan Ram

Thomas Hawtin said:
Does SQL have keyword arguments?

In a sense, as long as the syntax is considererd, albeit with
different semantics. I recently thought about SQL notation as
a general-purpose programming language:

It is known that Lisp is a general purpose and Turing complete
language, using only expression of the atom form or list form:

( f x y ... z )

where each letter might be an atom or a list itself, such as in

( f ( g x ) y )

Now, my idea was to write this (abusing SQL) as:

SELECT * FROM F
WHERE ARG =( SELECT * FROM G WHERE ARG = X )
AND ARG1 = Y;

This would even be able to handle nicely the multiple return
values, which are possible in Lisp. Some other features of the
SQL syntax are useful as well.

So one could implement a programming language based on SQL
syntax.
GridBagConstraints cons = new GridBagConstraints() {{ // Evil...
gridx = 0; gridy = 0; gridwidth = 2; gridheight = 1; ...
}};

Remarkable idea!

The SQL-syntax based notation could look like:

SELECT * FROM( SELECT NEW FROM GRID_BAG_CONSTRAINTS )
WHERE GRIDX = 0
AND GRIDY = 0
AND GRIDWIDTH = 2
AND GRIDHEIGHT = 1
AND ... ;
 
S

Stefan Ram

The SQL-syntax based notation could look like:
SELECT * FROM( SELECT NEW FROM GRID_BAG_CONSTRAINTS )
WHERE GRIDX = 0
AND GRIDY = 0
AND GRIDWIDTH = 2
AND GRIDHEIGHT = 1
AND ... ;

I forgot the »cons =« part, which might be written as:

CREATE VIEW CONS AS
SELECT * FROM( SELECT NEW FROM GRID_BAG_CONSTRAINTS )
WHERE GRIDX = 0
AND GRIDY = 0
AND GRIDWIDTH = 2
AND GRIDHEIGHT = 1
AND ... ;
 
C

Chris Uppal

Thomas said:
GridBagConstraints cons = new GridBagConstraints() {{ // Evil...
gridx = 0; gridy = 0; gridwidth = 2; gridheight = 1; ...
}};

However, your colleagues might want to have words with you if they saw
that...

One hardly knows whether the mind capable of conceiving such a notion should be
venerated or incarcerated. Probably both...

Or that was my first thought. Thinking of it again, I'm unable to come up with
a single defensible reason why one should avoid the "evil" technique.

Nice idea !

-- chris
 
S

Stefan Ram

Chris Uppal said:
Or that was my first thought. Thinking of it again, I'm unable
to come up with a single defensible reason why one should avoid
the "evil" technique.

If I understood it correctly, the extending anonymous class
directly accesses the fields of its super class.

In general, this is not possible, because

- the field names might not be known (by the
documentation) and

- the fields might have been declared as »private« or

- such fields do not exist (there does not
need to be a field for every constructor
parameter).

Even, if the fields can be accessed, the super class should be
free to change the internal field names or structure, which
would break this code.
 
C

Chris Uppal

Stefan Ram wrote:

[me:]
Or that was my first thought. Thinking of it again, I'm unable
to come up with a single defensible reason why one should avoid
the "evil" technique.

If I understood it correctly, the extending anonymous class
directly accesses the fields of its super class.

In general, this is not possible, because [...]

Even, if the fields can be accessed, the super class should be
free to change the internal field names or structure, which
would break this code.

Not in this case -- those fields are /published/ (public or protected) and as
such cannot be removed or changed without breaking client code.
GridBagConstraints is /committed/ to retaining those fields /with/ their
current meaning. If the designers had wanted to avoid that commitment then
they would have made the fields "unpublished" (private or package private).

GridBagConstraints has offered a contract to its users. Thomas's technique is
(unless I've missed something) a perfectly valid, and in all senses legal, use
of the rights conferred by that contract.

(Needless to say, the wide-ranging commitment implied by publishing (in my
sense) instance fields is why one is normally advised not to do so....)

-- chris
 
T

Thomas Hawtin

Chris said:
Not in this case -- those fields are /published/ (public or protected) and as

Yes, a good reason not to use protected. Event if they weren't fields,
you could still use set methods in the same way. Pity about the Java
syntax overuse of punctuation for straightforward method calls. It's as
if logical shift right is a more normal thing to do than call a method.
GridBagConstraints has offered a contract to its users. Thomas's technique is

It's not my technique! I didn't do it!!1!
(unless I've missed something) a perfectly valid, and in all senses legal, use
of the rights conferred by that contract.

Just because something is legal, doesn't mean that it's alright to do.

Tom Hawtin
 
T

Thomas Hawtin

Where is the overuse of punctuation?

Calling a method in Java looks like

object.method(arg0, arg1);

It could be written as

object method arg0 arg1

Saves the ., (, ,, ) and ;.

Tom Hawtin
 
T

Timo Stamm

Chris said:
One hardly knows whether the mind capable of conceiving such a notion should be
venerated or incarcerated. Probably both...

Or that was my first thought. Thinking of it again, I'm unable to come up with
a single defensible reason why one should avoid the "evil" technique.

September last year, we were discussing features of C# 3.0 in
de.comp.lang.java. C# already has properties, and in combination with
the generic initializer, it allows syntax like this:

new Point() { X = 1, Y = 2 }

It is obvious that this need much less code than overloaded constructors
and is more readable at the same time. I suggested to use the
initializer of Java to achieve a similar syntax:

new Point() {{x = 1; y = 2;}};


It has disadvantages:

- requires an anonymous class for each instance
- code formatters will format it to several lines
- only final variables local variables and field members are accessible

But I wouldn't think of it as "evil". It's unusual and has a few
restrictions, but if I ever come into a situation where I can benefit
from it and the restrictions don't apply, I will not hesitate to use it.


Timo
 
T

Thomas Hawtin

Stefan said:
The semicolon is not part of the method invocation but of the
expression statement.

Irrelevant. It is still necessary for the language, but not necessary
for humans.
Here you use spaces instead of ».«, »(«, »,« and »)«, which
actually does not change the number of characters used. The
characters ».«, »(«, »,« and »)« were just being replaced with
other characters (spaces).

I didn't claim to reduce the file size. I do claim that it reduces
unnecessary noise.
When combined with other expressions, additional parentheses
and separators might be needed. Then, to avoid forgetting
them, style guides might suggest to always use them (as the
braces after »if( ... )« or for the reason that the semicolon
in C /terminates/ statements and does not /separate/ them).
Eventually, one might end somewhere near the notation we use
today.

Similar to the notation we use today, if we were using Python. if(){}
can be replaced with if and appropriate whitespace (indentation).
Parentheses for bracketing are still needed, but then they are in Java
as well.

Tom Hawtin
 
R

Roedy Green

For readability, one would actually like to have keyword
arguments as in Smalltalk, SQL or VBA. As in

I do it with a comment line that aligns with the data. I have to
manually keep fiddling with the spacing though to maintain the
alignment.

Look at my original example. Unfortunately the spaces are squeezed out
so it is not obvious how it works.
 
S

Stefan Ram

Thomas Hawtin said:
Calling a method in Java looks like
object.method(arg0, arg1);

The semicolon is not part of the method invocation but of the
expression statement.
It could be written as
object method arg0 arg1

Here you use spaces instead of ».«, »(«, »,« and »)«, which
actually does not change the number of characters used. The
characters ».«, »(«, »,« and »)« were just being replaced with
other characters (spaces).

When combined with other expressions, additional parentheses
and separators might be needed. Then, to avoid forgetting
them, style guides might suggest to always use them (as the
braces after »if( ... )« or for the reason that the semicolon
in C /terminates/ statements and does not /separate/ them).
Eventually, one might end somewhere near the notation we use
today.
 
R

Roedy Green

- only final variables local variables and field members are accessible

I did a double take on that. Then I realised what you meant is you can
reference final local variables for use as values in initialising
member variables, not for initialising final locals.
 
S

Steve Wampler

Thomas said:
Calling a method in Java looks like

object.method(arg0, arg1);

It could be written as

object method arg0 arg1

Saves the ., (, ,, ) and ;.

And converts whitespace into lexicons :(

Consider a.b.c.d.e(x,y,z): a b c d e x y z

How fun. And if that wasn't enough

try: a(b,c).d(e,f): a b c d e f

Let's stick with what we have.
 
T

Timo Stamm

Roedy said:
I did a double take on that. Then I realised what you meant is you can
reference final local variables for use as values in initialising
member variables, not for initialising final locals.

Yes, that's what I meant. Thanks for formulating it in an understandable
way :)


Timo
 
S

Stefan Ram

Thomas Hawtin said:
Irrelevant. It is still necessary for the language, but not necessary
for humans.

A method invocation in Java does not have to be the statement
expression of an expression statement. It also might be part
of another expression or might be the controling expression of
an if, while, for or switch statement, in which case it is not
directly followed by a semicolon.
 

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,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top