On Fri, Aug 21, 2015 at 5:03 AM, 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…
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
