Would take much more fancy dancing in the JVM spec (compared to Tuples, which is pretty much JVM independent), so its a bit heavier in that sense, but its not bad. I bet some people are going to get annoyed at the notion that you need to define a struct separately, but personally an extra line or two, as long as its short, sweet, and to the point, is good.
But, if they don't have methods, then how can you quickly print one out or even inspect one for debug purposes? Other than that, this might be the easiest way around the issues. On Feb 26, 1:31 am, Alan Kent <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
