IMO, when you are talking about a type as primitive as a Date, then there is nothing wrong with ifNil: checks. You wouldn't want to do the same for Strings or Numbers. Date is right there with those.
More broadly, I feel there is nothing inherently wrong with case-logic if it is TSTTCPW. In fact, I'm even against delgation if something exists only in one place and low chance for future expansion, etc. On Thu, Aug 20, 2015 at 4:03 PM, Sean P. DeNigris <[email protected]> wrote: > I'm working on Issue 16136: "DateModel: Allow nil" > https://pharo.fogbugz.com/default.asp?16136 > > The idea is that DateModel should allow the possibility of no date (i.e. > date = nil) because some applications require this. > > Here are three possible implementations: > 1. #ifNil: checks; I already implemented this simple solution in > Spec-PolyWidgets-SeanDeNigris.59 (Pharo 4.0 based) and committed to > http://smalltalkhub.com/mc/SeanDeNigris/SeansOutbox/main/ > 2. Use UndefinedObject as a null object; this would probably require adding > an extension message to both Date and UndefinedObject, because it must be > specific enough not to reasonably conflict with other users > 3. Use a custom NoDate Null Object; the obvious advantage is that Date > remains unchanged, and NoDate just gets a (very) partial implementation of > its protocol; the disadvantage is that an extra class is introduced into > Core. > > Which, as a general guideline, do we prefer in Core? #3 seems to be the > universal OOP advice, but… > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Design-Question-Undefined-vs-MyNullObject-vs-ifNil-tp4844661.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >
