2015-08-20 23:03 GMT+02:00 Sean P. DeNigris <sean@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-tp4...
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.