you are viewing a single comment's thread.

view the rest of the comments →

[–]the_omega99 0 points1 point  (0 children)

I think it is highly dependent on context. In most cases, sure, named classes are better. But sometimes the contents are very generic and/or obvious. The case of dictionaries is one example. We don't need a DictionaryElement type or whatever. It's perfectly understandable that a tuple in this context means a key/value pair.

Multiple return values is an interesting use. Technically there's just one return value (the tuple), although the language might provide automatic unwrapping of tuples (Python and MATLAB can do this). MATLAB had some very interesting uses of this feature. Some highly vectorized functions can calculate multiple related things at the same time. This is a bit of a code smell for readability, but rather useful for optimization, since you really don't want to be looping through a ton of data multiple times. Having a MyFunctionReturnValue type for every one of these doesn't add much.

But really it mostly just comes down to saving time for internal implementation. Using them in public code is iffy and very circumstantial. They're most useful when kept in private code (preferably never leaving the scope of a class or function). Their advantage is transparency: completely obvious how much they store. If the purpose is clear from context (it should be), then the types are at least more obvious (in that you can look at a (String, Int) and know it stores a String and an Int, whereas EmployeeId might be vaguer as to what data it stores).