Re:True, False And Nil Objects In Ruby
by stcredzero on Tuesday September 08, 2009 @10:34AM
(#811069)
That's one of the biggest issues I have with monkey patching of builtin classes in Ruby or Smalltalk: it's not scoped/namespaced.
In Smalltalk, the right thing to do is use a subclass. Have that function return an instance of a subclass of UndefinedObject that's tailored to the context. Instead of returning nil, return a NotApplicable instance. Then you can have it print out a locale appropriate 'n/a' message when you need to display the value.
That's a potential solution in any language (you don't even have to extend a none/nil/whatever object), but it doesn't help interact with standard or third-party libraries which return `nil` already.
Re:True, False And Nil Objects In Ruby
by stcredzero on Wednesday September 09, 2009 @02:18AM
(#812644)
My stock solution to libraries with, let's call it, "substandard polymorphism" -- facades and/or wrappers. This often lets you put all of your conditional logic for dealing with the errant library in just one place. It's better than nothing. Sometimes, it's a lot better.
It's also pretty dangerous if you don't have a very good test coverage (and good tests), because it hides potential bugs. And it can break code which relies on the default behavior of `nil` (or other built-in objects).
That's one of the biggest issues I have with monkey patching of builtin classes in Ruby or Smalltalk: it's not scoped/namespaced.
edit: by comparison, Haskell's operators redefinition is scoped, so though you can redefine `+` as `-`:
this redefinition will only span your module and won't affect third-party library (unless you export the change and they import it for course).