Design Question: Undefined vs. MyNullObject vs. #ifNil:
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-tp4... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
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
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.
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 <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â¦
----- 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.
participants (4)
-
Ben Coman -
Chris Muller -
Nicolai Hess -
Sean P. DeNigris