3 ms·

Imo named tuples via records are better than tuples provided at the primitive level. They provide a ton more context for the next reader about what this thing

by vips7L 4y ago

Imo named tuples via records are better than tuples provided at the primitive level. They provide a ton more context for the next reader about what this thing actually is.

yarg 4y ago
It'd be nice if you could inline the Tuple description into the method signature. There's a bit of unnecessary overhead in having to externally declare and import the return type. public [K key, V value] getElement(int index); This really comes down to the dynamic vs typed argument, and to me the answer is "minimise the boiler-plate, maximise the guarantees.".
- haimez 4y ago
  I think declaration vs use Sue distinction is much more helpful to reason about in this context, and named tuples are a classic example of “if you didn’t declare these tuples to be compatible at definition time, it’s probably a bug to let you pass them around as if they were”
  - yarg 4y ago
    Codesmell sure - and a case for refactoring, but I wouldn't go as far as to say bug. But I wouldn't expect that to be the common use case - I'd generally expect that the caller would just be implicitly importing and using the type effectively declared in the method header.
titzer 4y ago
In Virgil, you can have it either way, anonymous tuple types with members indexed with .N, or flattened data types (without identity) with field names: var p: (int, int) = (0, 0); var q = p.0 + p.1; type Point(x: int, y: int) #unboxed { } var p = Point(0, 0); var q = p.x + p.y; Both will generate identical machine code with no allocations. It requires no escape analysis or assumption of non-identity (both tuples and data types have structural equality).
masklinn 4y ago
> They provide a ton more context for the next reader about what this thing actually is. Right until there’s no more context than “this returns 2 elements” and you end up with 15 different Pair types and more verbosity for no value. Named tuples are not better than tuples, they’re complementary, both are useful tools.
- vips7L 4y ago
  There's definitely always more context than "this returns 2 elements". What are they? What are you storing them in? What did they belong to?
  - masklinn 4y ago
    > There's definitely always more context than "this returns 2 elements". Not usefully so. If you’re splitting a collection in two, whatever context you add is almost certainly worthless overhead not worth the extra type.
  - titzer 4y ago
    I'm trying to let programmers make the call here, which is why Virgil gives you both options. In causal hacking, anonymous tuples can be very useful. I find that very true in test code, where I have a tendency to throw more bells and whistles at it to get meat of the tests really short (so I can write a lot of them). Requiring elaborate ceremonies (such defining a bunch of tuple types for no good reason) is just a waste of time.
deleted 4y ago
[deleted]

by vips7L 4y ago

Imo named tuples via records are better than tuples provided at the primitive level. They provide a ton more context for the next reader about what this thing actually is.

yarg 4y ago

It'd be nice if you could inline the Tuple description into the method signature. There's a bit of unnecessary overhead in having to externally declare and import the return type. public [K key, V value] getElement(int index); This really comes down to the dynamic vs typed argument, and to me the answer is "minimise the boiler-plate, maximise the guarantees.".

haimez 4y ago
I think declaration vs use Sue distinction is much more helpful to reason about in this context, and named tuples are a classic example of “if you didn’t declare these tuples to be compatible at definition time, it’s probably a bug to let you pass them around as if they were”
- yarg 4y ago
  Codesmell sure - and a case for refactoring, but I wouldn't go as far as to say bug. But I wouldn't expect that to be the common use case - I'd generally expect that the caller would just be implicitly importing and using the type effectively declared in the method header.

titzer 4y ago

In Virgil, you can have it either way, anonymous tuple types with members indexed with .N, or flattened data types (without identity) with field names: var p: (int, int) = (0, 0); var q = p.0 + p.1; type Point(x: int, y: int) #unboxed { } var p = Point(0, 0); var q = p.x + p.y; Both will generate identical machine code with no allocations. It requires no escape analysis or assumption of non-identity (both tuples and data types have structural equality).

masklinn 4y ago

> They provide a ton more context for the next reader about what this thing actually is. Right until there’s no more context than “this returns 2 elements” and you end up with 15 different Pair types and more verbosity for no value. Named tuples are not better than tuples, they’re complementary, both are useful tools.

vips7L 4y ago
There's definitely always more context than "this returns 2 elements". What are they? What are you storing them in? What did they belong to?
- masklinn 4y ago
  > There's definitely always more context than "this returns 2 elements". Not usefully so. If you’re splitting a collection in two, whatever context you add is almost certainly worthless overhead not worth the extra type.
- titzer 4y ago
  I'm trying to let programmers make the call here, which is why Virgil gives you both options. In causal hacking, anonymous tuples can be very useful. I find that very true in test code, where I have a tendency to throw more bells and whistles at it to get meat of the tests really short (so I can write a lot of them). Requiring elaborate ceremonies (such defining a bunch of tuple types for no good reason) is just a waste of time.

deleted 4y ago

[deleted]