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 -~----------~----~----~----~------~----~------~--~---
