2015-08-20 23:03 GMT+02:00 Sean P. DeNigris <s...@clipperadams.com>: > > 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… > >
I think this highly depens on how *useful* the null object would be, apart from being a "no-date". For example, if the user of the DateModel only use the string representation of the Date/NoDate object, they don't have to care about the real type, either they get a date string (21 August 2015) or an empty string. But the usage of Date objects is too general, the user of the DateModel will end up with replacing ifNil-checks with ifNullDate-checks. > > > ----- > 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. >
