Hi,
Due to other commitments I have only skim read read all the thread on
tuples, pairs (and skipped bits). But I thought I would throw up an
alternative (that has almost certainly be suggested before somewhere).
It is an obvious hijack of C/C++ structs (I don't know C# structs so
might be the same as that). Certainly nothing out of the ordinary - but
to me that is the goal. Something simple and easy to understand.
Instead of tuples with members named by index, why not introduce structs
with the following behavior. (My rationale is I like multiple value
returns, but I dislike having to remember the first value is A, the
second value is B, and oh - what happens if they are both int's but the
programmer reverses the order. No compile time errors, just brokent code.
So my variation (trying to keep things simple) is:
* A struct is NOT an object. It has no methods. It does not
inherit from Object. It does not have .equals().
* Structs are declared at the same scope as classes (i.e. can be
global, or nested, just like classes)
* Structs are defined by a list of fields (no methods)
o struct MyStruct { int a; List<Object> B };
* Structs have 2 automatic constructors defined
o One zero argument constructor - MyStruct(); - uses default
initializers for all members, and is the default initializer
for a non-initialized variable declared with a struct type.
o One constructor with an argument per field - MyStruct(3, new
List<Object>());
* Structs are not objects - you do not use 'new'. Internally they
are implemented just like declaring all the variables in the
struct yourself.
* Passing a struct as an argument to a function internally is
implemented with the same semantics as passing all the fields
individually - that is, struct contents are copied
* Returning a struct is like having a multi-valued return from a
function (not in Java at present). All the values are on the stack.
* All the semantics of default initialization, copying, etc for
structs is the same as doing those operations on the individual
members
* Probably cannot use a struct type as a generic parameter - that
might be too hard to do in practice (currently generic parameters
have to be Objects) - so a struct is more like a primitive type
like 'int' and 'double' than an object.
I like structs over tuples as you get meaningful names for the members.
struct Point { int x; int y; } The caller also does not need to worry
if the members of the struct change, since they access by meaningful name.
Example code
struct Point { int x; int y; }
class Rectangle {
private Point upperLeft;
private Point lowerRight;
public Rectangle(Point uppertLeft, Point lowerRight) {
this.upperLeft = upperLeft;
this.lowerRight = lowerRight;
}
public Point centroid() {
return Point((lowerRight.x - upperLeft.x) / 2, (lowerRight.y -
upperLeft.y) / 2));
}
}
...
Rectangle r = new Rectangle(Point(1, 1), Point(3, 3));
Point c = r.centroid();
System.out.println("Centroid is " + c.x + ", " + c.y);
...
I doubt this would make a simple language feature list though - too much
debate about how object like a struct should be I bet!
Another variation is to call it a tuple, but mandate tuples have named
fields. Giving the tuple a name (that is, calling it a struct) was
useful if you did not have implicit declarations - you can reuse the
type name easily.
Sorry, this is probably a repeat of previous stuff. But I really
dislike unnamed members of tuples from a code maintenance perspective,
which prompted this post.
Alan
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
