4 ms·

While I agree with the idea of the article, what's the logic for not using "small types" for all parameters? Or, to put it another way, how do you decide a give

by iaskwhy 12y ago

While I agree with the idea of the article, what's the logic for not using "small types" for all parameters? Or, to put it another way, how do you decide a given method should have "small types" used for parameters? Also, although it makes the code much more verbose, named parameters (as used in, for example, Objective-C) fix any eventual bug with refactoring methods' signatures, right?

benaiah 12y ago
The example given in this post doesn't show this, but what using types allows us to do is understand what a specific value is throughout its whole lifetime through all sorts of functions. We know that this vector is a velocity, and our compiler knows that too, so we can't unwittingly treat it as an acceleration vector further on down the line, whether that's done when passing it to another function, declaring variables, adding things together, or what-have-you. You are right that the specific example shown in the article can be achieved with simple named parameters, but that's a very small and specific application of the very broad protection that proper type use gives you.
TheLoneWolfling 12y ago
Named parameters don't help in the case where you have (for example) one function returning (pos, size) and another function expecting (size, pos).
Terr_ 12y ago
> Or, to put it another way, how do you decide a given method should have "small types" used for parameters? I think a good rule of thumb is to ask yourself what the "dimension" or "unit" the parameter has. (See also: Dimensional Analysis.) You never want to pass 4.33f radians into a function expecting 4.33f newtons! A few more examples: Distance in meters, Distance in feet, Speed in m/s, speed in yards/minute, Acceleration in m/s^2, Acceleration in cm/s^2, Mass in grams, Weight in pounds, Force in newtons, Force in dynes, Temperature in Celsius, Temperature in Fahrenheit, Angles in radians, Angles in degrees.... "But I don't do physics programming!", you say? Well, there's plenty more: Time in seconds, Time in milliseconds, Distance in pixels, Distance in inches, Numeric ID of a Foo, Numeric ID of a Bar, Bytes in UTF8, Bytes in ASCII, US currency in dollars, US currency in cents, Euros, interest rate (yearly), interest rate (monthly)... And that's not even getting into industry-specific dimensions that might exist.
- iaskwhy 12y ago
  Ok, I can understand that logic but then you might end up with dozens and dozens of "small types" so, as far as I understand, those who try to follow that paradigm have no problem whatsoever with the potentially high number of these types, is it so? (Again, asked another way, is it ever a problem to create a "small type" if it follows that rule? For some codebases it might mean having a "small type" per unique parameter on signatures.)
  - Terr_ 12y ago
    > Again, asked another way, is it ever a problem to create a "small type" if it follows that rule? IMO the biggest problem isn't having too many distinct types, because they represent information you'd need to track manually anyway, like knowing that $time is seconds rather than milliseconds. I'd be more worried about: 1. The risk of conflicts between different groups of people who both defined their own type called called "Newtons" and want their libraries to work together. 2. The sliding-scale of inconvenience if your implementation gets in the way of the mathematics, like having to call `foo.asFloat() * 2` rather than `foo * 2`. (You can relax things a bit by relying on best-effort annotations.)
    - iaskwhy 12y ago
      Thank you for your insights, it's always great to learn new things :)
- dragonwriter 12y ago
  > Distance in meters, Distance in feet That brings up an interesting issue -- is the "right way" to do that to have different types for these, or one type for distance with different factory function/methods for different units. E.g.: should "meters" and "feet" be different types, or should the "measurement" module have both a "meters" and "feet" method that return the same ("distance") type. It seems to me the latter is more conceptually clean. OTOH, math might be easier to express with the former (particularly in a language that allows you to define implicit type conversions, so that if you pass an "inch" value to a function expecting a "cm" parameter, it gets automatically converted to the appropriate "cm" value.)

by iaskwhy 12y ago

benaiah 12y ago

The example given in this post doesn't show this, but what using types allows us to do is understand what a specific value is throughout its whole lifetime through all sorts of functions. We know that this vector is a velocity, and our compiler knows that too, so we can't unwittingly treat it as an acceleration vector further on down the line, whether that's done when passing it to another function, declaring variables, adding things together, or what-have-you. You are right that the specific example shown in the article can be achieved with simple named parameters, but that's a very small and specific application of the very broad protection that proper type use gives you.

TheLoneWolfling 12y ago

Named parameters don't help in the case where you have (for example) one function returning (pos, size) and another function expecting (size, pos).

Terr_ 12y ago

> Or, to put it another way, how do you decide a given method should have "small types" used for parameters? I think a good rule of thumb is to ask yourself what the "dimension" or "unit" the parameter has. (See also: Dimensional Analysis.) You never want to pass 4.33f radians into a function expecting 4.33f newtons! A few more examples: Distance in meters, Distance in feet, Speed in m/s, speed in yards/minute, Acceleration in m/s^2, Acceleration in cm/s^2, Mass in grams, Weight in pounds, Force in newtons, Force in dynes, Temperature in Celsius, Temperature in Fahrenheit, Angles in radians, Angles in degrees.... "But I don't do physics programming!", you say? Well, there's plenty more: Time in seconds, Time in milliseconds, Distance in pixels, Distance in inches, Numeric ID of a Foo, Numeric ID of a Bar, Bytes in UTF8, Bytes in ASCII, US currency in dollars, US currency in cents, Euros, interest rate (yearly), interest rate (monthly)... And that's not even getting into industry-specific dimensions that might exist.

iaskwhy 12y ago
Ok, I can understand that logic but then you might end up with dozens and dozens of "small types" so, as far as I understand, those who try to follow that paradigm have no problem whatsoever with the potentially high number of these types, is it so? (Again, asked another way, is it ever a problem to create a "small type" if it follows that rule? For some codebases it might mean having a "small type" per unique parameter on signatures.)
- Terr_ 12y ago
  > Again, asked another way, is it ever a problem to create a "small type" if it follows that rule? IMO the biggest problem isn't having too many distinct types, because they represent information you'd need to track manually anyway, like knowing that $time is seconds rather than milliseconds. I'd be more worried about: 1. The risk of conflicts between different groups of people who both defined their own type called called "Newtons" and want their libraries to work together. 2. The sliding-scale of inconvenience if your implementation gets in the way of the mathematics, like having to call `foo.asFloat() * 2` rather than `foo * 2`. (You can relax things a bit by relying on best-effort annotations.)
  - iaskwhy 12y ago
    Thank you for your insights, it's always great to learn new things :)
dragonwriter 12y ago
> Distance in meters, Distance in feet That brings up an interesting issue -- is the "right way" to do that to have different types for these, or one type for distance with different factory function/methods for different units. E.g.: should "meters" and "feet" be different types, or should the "measurement" module have both a "meters" and "feet" method that return the same ("distance") type. It seems to me the latter is more conceptually clean. OTOH, math might be easier to express with the former (particularly in a language that allows you to define implicit type conversions, so that if you pass an "inch" value to a function expecting a "cm" parameter, it gets automatically converted to the appropriate "cm" value.)