3 ms·

As someone who has only played with Ruby briefly, and at that many years ago, I feel that this article could have done more to explain the author's concepts to

by com2kid 13y ago

As someone who has only played with Ruby briefly, and at that many years ago, I feel that this article could have done more to explain the author's concepts to those not familiar with Ruby. From what I can see, how is this much different than a Null check? I agree it looks a bit better, but what is the real difference? Isn't there still a check for if the Person object exists? In terms of C++ or C#, is it correct to imagine this as an iterator over one object where inside my iteration loop I am passing my object into a lambda? (Seems overly complicated so I am guessing this is the wrong interpretation?) Indeed a post at the bottom of the page mentions using foreach, but since sane languages have closures now days (thankfully! Life is so much better now!), how would I apply this to, say, C++?

Strilanc 13y ago
The difference is that the null check is front and center, instead of hidden. In C# or Java, the member access expression "a.b" contains a null check. There's no way to do a member access that doesn't do a null check (for reference types)! It's impossible to distinguish member accesses that were expected/assumed by the writer to not fail from member accesses where the check is relied upon. With an option type / a maybe monad / 'using telling instead of finding', there are no implicit null checks. Only explicit checks, and only when necessary. Either you use Option.map, to do a check and propagate nulls, or you don't, in which case there's no null path. You don't have to worry about null reference exceptions, making a check where you shouldn't, or missing a check where you should have, because the compiler prevents you from making those mistakes. Applying it to C++: https://github.com/simonask/simonask.github.com/blob/master/maybe.markdown https://github.com/simonask/simonask.github.com/blob/master/... Applying it to C# (as an augment over null): http://twistedoakstudios.com/blog/Post1130_when-null-is-not-enough-an-option-type-for-c http://twistedoakstudios.com/blog/Post1130_when-null-is-not-... Applying it to Java (as an alternative to null): http://java.dzone.com/articles/java-optional-objects http://java.dzone.com/articles/java-optional-objects
- topbanana 13y ago
  Off-topic but I find the color scheme of your blog very offputting
enobrev 13y ago
The difference seems to be that instead of checking for whether a single object is returned, to actually check for the size of the collection returned, which (depending on your language, of course) the method used to iterate over that collection does automatically.
dragonwriter 13y ago
> From what I can see, how is this much different than a Null check? I agree it looks a bit better, but what is the real difference? The difference is that the "teller" function incorporates both the function of the finder (which may actually still exist and be used under the hood) and the function of the null check, so that you don't have the boilerplate null-check code every time you need to do a null check. (It may not actually be doing a null check per se, the finder-equivalent may be returning a set of 0 or 1, or 0 to many if using non-exclusive criteria, and the teller iterating over it, but for inherently unique criteria it could be a finder that returns a single object or null underneath. While whether the criteria inherently will always return at most one or potentially multiple objects to operate on may be important to the caller, the underlying implementation isn't.) > In terms of C++ or C#, is it correct to imagine this as an iterator over one object where inside my iteration loop I am passing my object into a lambda? The most general teller implementation would operate as an iteration over a collection returned by the finder; for finders with inherently unique criteria, that collection would always have either zero members or one member. Particular teller implementations may or may not use that general implementation. For unique cases, the teller could just be a call to the finder with a null check guarding a call to the lambda that passes the non-null result of the finder.
gwright 13y ago
The difference is that the API has changed from: search_for_object_in_database which returns the result or a failure indication to: if_object_in_database_do { this_with_the_object } The handling of a failed search is now internal to the API instead of in the client code. In this example, 'this' is simply not executed if the search fails. The client code is passing instructions on what to do when the search succeeds instead branching on success or not. The idea of passing code in addition to data is a powerful one and when the language makes it easy (Ruby blocks, Javascript function objects, lisp functions) it really does change the way you think about the design of APIs.
sageikosa 13y ago
foreach (var myObject in dataSource.getObjectsByID(id)) { myObject.DoStuff(); } Twasn't so hard, as long as you don't make your data API return singletons.

by com2kid 13y ago

Strilanc 13y ago

The difference is that the null check is front and center, instead of hidden. In C# or Java, the member access expression "a.b" contains a null check. There's no way to do a member access that doesn't do a null check (for reference types)! It's impossible to distinguish member accesses that were expected/assumed by the writer to not fail from member accesses where the check is relied upon. With an option type / a maybe monad / 'using telling instead of finding', there are no implicit null checks. Only explicit checks, and only when necessary. Either you use Option.map, to do a check and propagate nulls, or you don't, in which case there's no null path. You don't have to worry about null reference exceptions, making a check where you shouldn't, or missing a check where you should have, because the compiler prevents you from making those mistakes. Applying it to C++: https://github.com/simonask/simonask.github.com/blob/master/maybe.markdown https://github.com/simonask/simonask.github.com/blob/master/... Applying it to C# (as an augment over null): http://twistedoakstudios.com/blog/Post1130_when-null-is-not-enough-an-option-type-for-c http://twistedoakstudios.com/blog/Post1130_when-null-is-not-... Applying it to Java (as an alternative to null): http://java.dzone.com/articles/java-optional-objects http://java.dzone.com/articles/java-optional-objects

topbanana 13y ago
Off-topic but I find the color scheme of your blog very offputting

enobrev 13y ago

The difference seems to be that instead of checking for whether a single object is returned, to actually check for the size of the collection returned, which (depending on your language, of course) the method used to iterate over that collection does automatically.

dragonwriter 13y ago

> From what I can see, how is this much different than a Null check? I agree it looks a bit better, but what is the real difference? The difference is that the "teller" function incorporates both the function of the finder (which may actually still exist and be used under the hood) and the function of the null check, so that you don't have the boilerplate null-check code every time you need to do a null check. (It may not actually be doing a null check per se, the finder-equivalent may be returning a set of 0 or 1, or 0 to many if using non-exclusive criteria, and the teller iterating over it, but for inherently unique criteria it could be a finder that returns a single object or null underneath. While whether the criteria inherently will always return at most one or potentially multiple objects to operate on may be important to the caller, the underlying implementation isn't.) > In terms of C++ or C#, is it correct to imagine this as an iterator over one object where inside my iteration loop I am passing my object into a lambda? The most general teller implementation would operate as an iteration over a collection returned by the finder; for finders with inherently unique criteria, that collection would always have either zero members or one member. Particular teller implementations may or may not use that general implementation. For unique cases, the teller could just be a call to the finder with a null check guarding a call to the lambda that passes the non-null result of the finder.

gwright 13y ago

The difference is that the API has changed from: search_for_object_in_database which returns the result or a failure indication to: if_object_in_database_do { this_with_the_object } The handling of a failed search is now internal to the API instead of in the client code. In this example, 'this' is simply not executed if the search fails. The client code is passing instructions on what to do when the search succeeds instead branching on success or not. The idea of passing code in addition to data is a powerful one and when the language makes it easy (Ruby blocks, Javascript function objects, lisp functions) it really does change the way you think about the design of APIs.

sageikosa 13y ago

foreach (var myObject in dataSource.getObjectsByID(id)) { myObject.DoStuff(); } Twasn't so hard, as long as you don't make your data API return singletons.