> On Jan 5, 2015, at 12:00 PM, Norbert Hartl <norb...@hartl.name> wrote: > >> >> Am 05.01.2015 um 14:43 schrieb Sebastian Sastre >> <sebast...@flowingconcept.com <mailto:sebast...@flowingconcept.com>>: >> >> one hugely typical case is having the model of an input that has either nil >> because is pristine or an empty string and the app needs to guarantee some >> default value that should not be nil or an empty string. >> >> Another frequent case is the response of some API that will typically answer >> nil or an empty collection when something is not found and you want to >> guarantee some value or model that should not be nil or an empty collection. >> >> About #thing being meaningless, sure, I’ve mentioned as general example. I >> don’t see that every user of #thing has to use the ifNilOrEmpty:, only those >> who care about guaranteeing that closure valued if none is found which is >> expressed in the completely sensible form of receiving nil or an empty >> collection :) >> > My point is that as long as you do not promise a certain type of object you > will have to deal with the uncertainty what methods you can call on that > object of uncertain type. By not using a check you just extend the life of > this uncertainty a while longer (bad if the user of your code has to deal > with it). Some has to deal with it if the object has to do something. And the > earlier this uncertainty is removed the better it is. At least in my opinion. > > Norbert
Ah! I understand your point better now, thanks for clarifying. Actually you helped me to understand better something I systematically do often which is extending that uncertainty as much as is convenient :) For example Mapless <http://sebastianconcept.github.io/Mapless> (and MiniMapless <https://github.com/flow-stack/MiniMapless>) gives you the freedom of not having to predict what instance variables your persistent objects will have and still gives you the features now. Is the opposite of the predictive certainty demanded by typed technologies and their the compiler is your friend BS that completely frustrates your creative flow. Dynamic technologies are all about delaying certainty. Late binding is delaying it until runtime. I don’t say this as a technicality, I see it as a useful tool to push the present into the future and pull the future into the present. Being able to reflect in real-time makes this possible. Is what makes easier to invent the future when they “touch" each other. If someone else has to deal with the object and code with this uncertainty, you know you’re on the right place for personal mastery <http://www.cs.virginia.edu/~cs655/readings/smalltalk.html> to happen since Smalltalk was designed to allow the individual to easily navigate code and master the system by itself. This is actually a major reason to choose Smalltalk. Thanks again!
