Smalltalk › Pharo › Pharo Smalltalk Developers

Design Question: Undefined vs. MyNullObject vs. #ifNil:

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

Sean P. DeNigris

Design Question: Undefined vs. MyNullObject vs. #ifNil:

Administrator

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

Ben Coman

Re: Design Question: Undefined vs. MyNullObject vs. #ifNil:

On Fri, Aug 21, 2015 at 5:03 AM, Sean P. DeNigris <[hidden email]> 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

Nicolai Hess

Re: Design Question: Undefined vs. MyNullObject vs. #ifNil:

In reply to this post by Sean P. DeNigris

2015-08-20 23:03 GMT+02:00 Sean P. DeNigris <[hidden email]>:
>
> 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.
>

Chris Muller-3

Re: Design Question: Undefined vs. MyNullObject vs. #ifNil:

In reply to this post by Sean P. DeNigris

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 <[hidden email]> wrote: