Indeed that is better idea!

Thanks Ben,

Vincent

-----Message d'origine-----
De : Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] De la part de Ben 
Coman
Envoyé : jeudi 13 août 2015 19:13
À : Any question about pharo is welcome
Objet : Re: [Pharo-users] Tabular: XLSX import

On Thu, Aug 13, 2015 at 10:37 PM, Blondeau Vincent 
<vincent.blond...@worldline.com> wrote:
>
>         > -----Message d'origine-----
>         > De : Pharo-users 
> [mailto:pharo-users-boun...@lists.pharo.org] De la part
>         > de H. Hirzel
>         > Envoyé : jeudi 13 août 2015 15:06
>         > À : Any question about pharo is welcome
>         > Objet : Re: [Pharo-users] Tabular: XLSX import
>         >
>         > On 8/13/15, Blondeau Vincent 
> <vincent.blond...@worldline.com>
> wrote:
>         >
>         > > I think the access to an empty cell should be nil.
>         >
>         > OK
>         >
>         > But what about
>         >
>         >      aCell data
>         >
>         > (aCell being nil)
>         >
>         > should it still give nil or the empty string?
>
> It should give nil. The string is not an expected representation of an 
> empty cell. You can put formula or strings in a cell, but nil 
> represent the lack of content.
> BTW, the cell can be not nil but the content can be... It is the case 
> where the cell has a style defined.
>

Wouldn't it be better now at the beginning to return an EmptyCell object. Then 
at some random time later someone wanting to add functionality that you can't 
imagine now can add ivars and methods to that class.  Also think about a future 
application evaluating cell A3 holding formula "=A1+A2" where A2 is empty.  Do 
you really want your library users to shoulder the burden of #isNil guarding 
each cell reference instead of having...

    EmptyCell >> value
         ^0

cheers -ben



Reply via email to