undefined | Better HN

0 pointsgpderetta4y ago0 comments

I don't think it is indispensable, I think it is convenient and still better than what is done today were types without clear domain and purpose are already passed around.

At the very least with row polymorphism, a function can declare which subset of the type it actually care about instead of taking an unwanted dependency on the whole blob.

In particular I'm considering the scenario were a large application (or better a collection of applications) evolve without a central plan and messages tend to grow to accommodate orthogonal requirements (the alternative is splitting the messages, but it has performance, complexity and organizational overhead).

In theory the alternative is message inheritance, but in my experience it has never worked well and it is very hard to retrofit anyway.

0 comments

naasking4y ago

> At the very least with row polymorphism, a function can declare which subset of the type it actually care about instead of taking an unwanted dependency on the whole blob.

This is the argument I no longer find convincing. Do you have an example where this is so much clearer than alternate, simpler ways of doing it?

For instance, in principle you could easily rewrite a function that works on a record with 3 fields to just accept 3 parameters. The only additional "burden" is that the caller has to pass in those 3 fields, where before they could just pass in the record.

int_19h4y ago

Having it as a single parameter precludes the mistake of passing unrelated values, though.

naasking4y ago

The row typed function is also less reusable for that reason.

If you have two fields of compatible type such that you can confuse which one to pass as a parameter, then it's likely you're not making enough domain specific type distinctions that would disambiguate these fields.

If these fields were really compatible domain specific types, then it's more likely you would want to be able to use that function with both fields at some point. Row typing then either hinders this reuse (not good), or requires you to refactor to encapsulate both fields in a new record with compatible fields and pass that in (maybe good?). This is code you wouldn't have to write without row types.

But as I said, I would like a concrete example to discuss if anyone has one. Speaking in abstract like this isn't likely to be convincing either way.

j / k navigate · click thread line to collapse

0 pointsgpderetta4y ago0 comments

I don't think it is indispensable, I think it is convenient and still better than what is done today were types without clear domain and purpose are already passed around.

At the very least with row polymorphism, a function can declare which subset of the type it actually care about instead of taking an unwanted dependency on the whole blob.

In theory the alternative is message inheritance, but in my experience it has never worked well and it is very hard to retrofit anyway.

0 comments

naasking4y ago

> At the very least with row polymorphism, a function can declare which subset of the type it actually care about instead of taking an unwanted dependency on the whole blob.

This is the argument I no longer find convincing. Do you have an example where this is so much clearer than alternate, simpler ways of doing it?

int_19h4y ago

Having it as a single parameter precludes the mistake of passing unrelated values, though.

naasking4y ago

The row typed function is also less reusable for that reason.

But as I said, I would like a concrete example to discuss if anyone has one. Speaking in abstract like this isn't likely to be convincing either way.

j / k navigate · click thread line to collapse