marcos toledo's programming blog

Raganwald has written a very elaborate piece about his “objection to Array#sum“. Since I patircularly like Array#sum, I thought I might weight in on my own blog.

First, I think that his piece has 2 different objections:

1) Array shouldn’t return true for a “responds_to? :sum” call if it has contents that can’t be summed ( like [1, 2, 'three'])

2) Some other object should be responsible for providing the “sum” service, as well as being responsible for inspecting the contents of the array for making sure they can be summed

Even though in his article he doesn make this distinction, I believe they are different issues.

So, my opinion to the first objection: “Should ‘responds_to? :sum’ always return true?”

Of course the answer to this is “yes”, even if ’sum’ was declared somewhere else instead of on the Array. The reason is that, as long as this function is not implemented in the array object, there’s no way to inspect its contents unless we pass a parameter to the ‘responds_to?’ method. And there’s no way to do that. The only parameter that ‘responds_to?’ receives is the method name. You can’t pass the method argument’s values to have a conditional return. The class either always responds to that method, or it doesn’t.

The same is true when you are writing interfaces for a statically typed language like Java. Interfaces only define 4 things: The method name, and the type of parameters it receives, the type of object it returns, and which errors does it throw. There’s no way to know if the method is supported for some particular set of parameters. The only thing you can know is what kind of errors the method throws if something goes wrong.

That’s exactly how an interface written in java would be if Array implemented a ’sum’ method. If you ignored generics, there’s no way you can conditionally implement that method on the Array class based on its contents. And there’s no way you can conditionally implement that interface in any other object either. There’s not even a way to support the method ’sum()’ on only ‘Array<Integer>’.

My point is, there’s no way you can inspect parameters or state to conditionally implement an interface. The interface is always tied to the class, not to the parameters of the method or to its state, and it will throw the declared errors if the situation arises.

The second quetion is: “Well, should then array#sum be moved to some other object or a standalone function which actually guarantees the semantic of the sum method?”

Well, I do think there’s a valid alternative to this, but I don’t think it’s neither having a standalone function ’sum()’  nor having some other ‘ArrayUtils#sum()’.

The reason why I don’t like any of the former alternatives is that there’s really no semantic gains or distinction by using any of the above compared to the old Array#sum. If you can call Array#sum in situations which are invalid and therefore it shouldn’t be supported, then there’s nothing that ArrayUtils#sum helps you with. If calling Array#sum doesn’t really tell you if that’s a semantically valid operation, calling sum() in any other fashion doesn’t really help either.

Besides, those alternatives create a pattern in code which I don’t like, which is the pre-chaning of calls. So, instead of:

['1', '2', '3', nil, '5'].compact.map(&:to_i).map {|i| i * 10}.sum

You now have:

sum(map(map(compact([1, '2', '3', nil, '5']), lambda {|i| i * 10}, lambda &:to_i )))

Or something like this (didnt really check this code for errors). Now, you have to read code from right to left. And if you argue that some things like map belongs to it and compact don’t, than you’ll have to read both from left to right and from right to left.

Particularly, having to read code from right to left sometimes is what I don’t like about lisp, and being able to chain a lot of calls and to read code from left to right is one of the reasons I like ruby so much.

So, given that exporting the method ’sum’ to another class still doesn’t help me tell if I can use it with a correct semantic meaning on an array any more than calling array#sum, I think it only brings the drawbacks above, without any of the benefits.

Now, I do think there could be a valid alternative to this: If had a NumberArray class. Then, I could check for the types of all the methods which change the state of the Array to make sure that whenever #sum was called, it would have a correct semantic meaning, since I’m enforcing its semantics both on my class name and on all my methods. And then I could remove the #sum method from the Array class and move it to the NumberArray class.

But then, that’s a design decision as any other when you have the following question: “Should I create a new type for providing this service? Or should I throw an error if it hasn’t been called correctly?”. The former has the benefit of having more semantically correct classes and services provided on them. The later has the benefit of not numerous numbers of types, and of being able to easily handle cases where both types are needed.

For instance, if you have Users that can delete another user, you could create a Admin specialization that implements the ‘delete_user’ service, so that you don’t have to throw errors when normal users try to delete users, which really doesn’t make sense. But if a user can delete another user if he has the same email address as the other user, then you’ll run into trouble, since you can’t inspect state to implement the Admin interface conditionally.

Being able to throw errors conditionally according to the state, rather than counting on object types and interfaces, can yield code that’s easier to read  than moving functions to some other objects, without being any less semantic. And it also allows for code that’s more flexible and extensible than moving code to specialized classes that carry more semantics. That’s really why I like Array#sum the way it is.