Many languages already have tuples, so I'd say any tuple proposal needs to think about how to add them in a way that e.g. a jython tuple is mostly interchangable with a java tuple.
On Feb 26, 11:55 am, Peter Becker <[email protected]> wrote: > Couldn't they just be objects on the JVM level? It seems sufficient if > the compiler constrains them. > > Peter > > Reinier Zwitserloot wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
