On 7/20/07, Tako Schotanus <[EMAIL PROTECTED]> wrote:
On 7/20/07, Alexandru Popescu ☀ <[EMAIL PROTECTED]> wrote:
>
> On 7/20/07, Tako Schotanus <[EMAIL PROTECTED]> wrote:
> > On 7/20/07, Alexandru Popescu ☀ <[EMAIL PROTECTED]>
> wrote:
> > >
> > >
> > > On the other side, I still think that there are cases where NULL and
> > > non-existant may mean different things.
> > >
> > > Confusing isn't it? :-)
> >
> >
> > To me there is no confusion, null in either a programming language or a
> DBMS
> > means the absence of value.
> >
>
> Well, I think this is still opened to debate ;-). A collection
> containing 2 values and 3 nulls is the same with a collection having
> only the 2 values? And I do think we can go very far with this
> discussion :-), so maybe we should agree that this is just a debatable
> topic.
It is not the same thing, true, but it is meaningless, what does having 3
null values in a collection _mean_? Even if it is possible to do so (many
collection implementations don't even allow you to add nulls) you could
probably exchange the null value for an empty object, which suggests that
they are interchangeable. Again, the fact that you would like to differ
between the two doesn't necessarily mean it's wise to do so.
> That YOU add a specific meaning to the absence of that value is okay, but
> it
> > is generally considered bad practice because it is not obvious just by
> > looking at the data what your intentions are. In those cases it is
> suggested
> > that you explicitly model the different states that you want to
> recognize.
> >
>
> You are totally right about this. But you should probably agree that:
> property.setValue(null) is not the same with property.remove() (it is
> only in the JCR spec).
Well, actually, no I don't agree. You have to think about what does it
_mean_, what does it mean to have a property that has no value?
I can see 2 options:
- either the mere existence of the property is enough, compare this with the
HTML <option ... selected> where it's enough for the property to exist, it
does not need a value. But in this case it actually doesn't matter what
value you choose for the property, it could be anything so you don't need
support for null (I think that many HTML DOM implementations just use the
name of the property as its value, eg selected="selected").
- or the property needs a value but is optional. So you can leave it out if
you want, or you could give it a value, you can even give it an empty value
if permitted by its data type, so you've already covered all reasonable
use-cases.
The fact that NULL exists in a database is because there is no other way to
determine the absence of data otherwise, but in in the hierarchical model
you can just leave out the data and that's it.
I just don't see any use-cases, except for contrived ones, that would merit
adding support for null values (at this moment anyway).
Well, if I am the only one making efforts to understand others view
points, then this discussion is useless :-(.
As a matter of fact, I've been designing APIs for quite a few years,
and I can guarantee you that setValue() should always have different
semantics than remove() (they are different at language level; and if
you check different API you'll see that almost everywhere this
difference is kept).
I will probably stop by now, considering that I brought enough details
to the discussion and presented my point. It is now up to the others
to see if they are valid/helpful or not -- I only hope that people
looking at it are trying to keep their mind opened as I am.
bests,
./alex
--
.w( the_mindstorm )p.
