On Fri, Aug 21, 2015 at 5:03 AM, Sean P. DeNigris <sean@clipperadams.com> 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â¦
What is you definition of Core? The standard released Image, or some minimal part? I suppose any extension message you might add for (2.) could just be added for (3.), so I see no advantage to that. (3.) facilitates a better paradigm for user-code, so is preferable. What is disadvantages you you perceive with adding an extra class? I can only think memory size, but you save code size eliminating #ifNil(s) from user-code cheers -ben