jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexandru Popescu ☀" <the.mindstorm.mailingl...@gmail.com>
Subject Re: 3.1.3.1 Removing Items
Date Fri, 20 Jul 2007 11:14:31 GMT
On 7/20/07, Tako Schotanus <quintesse@gmail.com> wrote:
> On 7/20/07, Alexandru Popescu ☀ <the.mindstorm.mailinglist@gmail.com> wrote:
> >
> > On 7/20/07, Tako Schotanus <quintesse@gmail.com> wrote:
> > > On 7/20/07, Alexandru Popescu ☀ <the.mindstorm.mailinglist@gmail.com>
> > 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.
Mime
View raw message