4 ms·

I fail to see how i.even? is any more convenient than even? i except that even? has now somehow entered into the set of functions worthy to be part

I fail to see how i.even? is any more convenient than even? i except that even? has now somehow entered into the set of functions worthy to be part of the integer-fake-object while others have not.

petercooper 15y ago
It's more consistent (no wondering what's a method and what's not for most common situations) and it stops the global namespace getting littered up with functions that are only relevant to certain types. To a Rubyist, knowing that Ruby is an object oriented language, it is clear one is sending a message to i. With the latter example, it is not clear what even? belongs to and what it expects to receive.
- Locke1689 15y ago
  Then namespace it. As I said, there's nothing stopping you from having namespaces and modules. import Arithmetic (even) even :: Integer -> Bool even i Also, you can call function calls messages or object operations or dictionary lookups, but I don't see the benefit in 99% of cases. I guess the dynamism may be useful in GUI code where it's not that hard to see if you're wrong and if you are wrong, nobody's world really ends. In most other cases functions are best described as having a formal mathematical definition so you can reason about them with some accuracy.
JonnieCache 15y ago
Because the former reads more like english. I would ask "is 2 even?" but I would never ask "does the quality of evenness apply to 2?" One of the things I dislike about python is the word order you end up with. My eyes have to jump about to work out whats going on. Its like german ;)
- Locke1689 15y ago
  Your order is like English, but your semantics are the exact opposite. My code asks "is 2 even?" -- it calls the even? function to check to see if it's a boolean. If you notice, the even? object function is referentially transparant and implicitly contains its own argument. It's not really a function. It's a field. What Ruby has done is define a field of every Integer instance which returns True or False based on a separate function call that determines whether or not the object is even. It's irrelevant how the function is implemented because those are the semantics -- you have defined a method that answers if the quality of evenness applies to 2. Your own example is exactly why I dislike the semantics of this object method.
  - JonnieCache 15y ago
    Yes, but I like it like that you see.

I fail to see how i.even? is any more convenient than even? i except that even? has now somehow entered into the set of functions worthy to be part of the integer-fake-object while others have not.

petercooper 15y ago

It's more consistent (no wondering what's a method and what's not for most common situations) and it stops the global namespace getting littered up with functions that are only relevant to certain types. To a Rubyist, knowing that Ruby is an object oriented language, it is clear one is sending a message to i. With the latter example, it is not clear what even? belongs to and what it expects to receive.

Locke1689 15y ago
Then namespace it. As I said, there's nothing stopping you from having namespaces and modules. import Arithmetic (even) even :: Integer -> Bool even i Also, you can call function calls messages or object operations or dictionary lookups, but I don't see the benefit in 99% of cases. I guess the dynamism may be useful in GUI code where it's not that hard to see if you're wrong and if you are wrong, nobody's world really ends. In most other cases functions are best described as having a formal mathematical definition so you can reason about them with some accuracy.

JonnieCache 15y ago

Because the former reads more like english. I would ask "is 2 even?" but I would never ask "does the quality of evenness apply to 2?" One of the things I dislike about python is the word order you end up with. My eyes have to jump about to work out whats going on. Its like german ;)

Locke1689 15y ago
Your order is like English, but your semantics are the exact opposite. My code asks "is 2 even?" -- it calls the even? function to check to see if it's a boolean. If you notice, the even? object function is referentially transparant and implicitly contains its own argument. It's not really a function. It's a field. What Ruby has done is define a field of every Integer instance which returns True or False based on a separate function call that determines whether or not the object is even. It's irrelevant how the function is implemented because those are the semantics -- you have defined a method that answers if the quality of evenness applies to 2. Your own example is exactly why I dislike the semantics of this object method.
- JonnieCache 15y ago
  Yes, but I like it like that you see.