Robert Klemme <bob.news / gmx.net> wrote:
> Klaus Stein wrote:
>> Robert Klemme <bob.news / gmx.net> wrote:
>>> Klaus Stein wrote:
>>>>
>>>> obj.meth1().meth2().nil_friendly.meth3()
>>>> ==========================================================
>>>>
>>>> [ ... ]
>>>>
>>>> Comments?
>>>
>>> What about #nil?
>>>
>> nil.nil? -> true
>> nil.nil_friendly.nil? -> false
>> We _either_ want to use #nil_friendly _or_ test for nil, so I don't
>> think this gives any problem. If I explicitly use #nil_friendly, I
>> say, that I don't care about this being nil, so I will not test for
>> nil.
> 
> I'm not sure I'm following you here.  If it's an expected nil (like for
> example an explicitely initialized instance variable) shouldn't this then
> behave similarly to nil with regard to this test?  I imagine there will be
> two equally sized camps in favour for each of the two options...
> 
Well, from my point of view the semantics of #nil_friendly simply is to not
return nil. I expect the object on which #nil_friendly is applied may be
nil, but i don't expect the result of #nil_friendly to be nil, why should I?
obj.nil_friedly is equal to (obj.nil? ? Blackhole.instance : obj)

I don't see why anyone should try something like obj.nil_friedly.nil?,
because I know that this will return false :-)

But I am interested if there are other real drawbacks?

Klaus
-- 
http://lapiz.istik.de/

The Answer is 42. And I am the Answer. Now I am looking for the Question.