Allow named TUPLE elements as defined by ECMA chapter 7.12 Tuples and agents:
It is also possible in the tuple type declaration to label the components, as in TUPLE[x: A; y: B; z: C], making it simpler to access the elements, as in your_tuple.y, with the proper type, here B, rather than your_tuple.item(2) of type ANY by default.
This is not much more than what already is in Liberty with item_x and set_item_x, but with user defined names.
I think this is a nice feature, which does not violate the simple language principles of Eiffel.
We shall document this on the wiki.
I also think it would be good to have a wiki page for "EMCA - What Liberty does (not) (yet) implement".
What do you think?
I think we should NOT implement this for Adler and decide after the Adler release whether we want it in Bell. I could imagine a "virtual" milestone "later" for exactly this type of feature requests. Or should we just assign it to bell and keep the option to move it to a later release when working on bell? Or is "no milestone assigned" exactly this?
"no milestone" + "feature request" tag together have the required semantics.
As for the request itself: it means an extensive work on the TUPLE implementation, departing from the SmartEiffel philosophy that the more in Eiffel, the better. With this change, the TUPLE class cannot be written in Eiffel anymore.
Second point, I tend to think of TUPLE as quick-and-dirty prototyping. As soon as you need something more than a few anonymous elements, you should write a proper class with a proper name.
Good arguments. - The second point I actually expected. But I'm not sure, whether we should be more "liberal" and "allow" the use of TUPLEs for objects without intelligence, which are just a typed structure. - But yes, I don't know how many use cases there are in real life, good styled projects.
For the first, I did not expect the TUPLE implementation to be fully in Eiffel and I'm still not convinced, that there is no special handling in the compiler ;-) And be honest the file tuple.e is not the best software engineering style you ever saw.
But, I need to think further about this to build an opinion. - Would be interesting to read further opinions of former SE users ;-(
Indeed it is no great code, but it does its job of being visible: all the TUPLE features are legible when opening tuple.e in an editor. Not so if the class is fully handled by the compiler.
On the other hand: named tuple fields have their member names in the code that uses them, so obvously there is no need to open tuple.e to see them :-)
I'd propose a mix: keep the current TUPLE implementation, with default member names, and allow named fields as aliases of the current item_1 etc. names. We only need to think about set_item features (since x.y := some is still not a valid construct).
I didn't want to suggest the removal of set_item_x. We shall definitely keep them as they are. If the named tuple elements are implemented in Liberty, the only way I see is your mix.
I also do not see a strong need to implement the named tuple aliases, though. But I also do not see a strong reason for not implementing it.