jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@gbiv.com>
Subject Re: 3.1.3.1 Removing Items
Date Mon, 23 Jul 2007 09:25:03 GMT
On Jul 21, 2007, at 10:01 AM, IvanLatysh wrote:
> Roy T. Fielding wrote:
>
>> I am sorry, but that is factually incorrect.  Please look it up in  
>> any
>> book on programming languages.  Null (or its synonyms, like undef  
>> in perl)
>> is a language feature for indicating that a name (pointer, object,
>> reference, etc.) does not exist.
> Since we are in the Java world so let's be precise.
> In Java `null` is a type and the reference and reference itself is  
> a value.
> [quote "Java Language Specification Second Edition"]
> There is also a special null type, the type of the expression null,  
> which has no
> name. Because the null type has no name, it is impossible to  
> declare a variable
> of the null type or to cast to the null type. The null reference is  
> the only
> possible value of an expression of null type.
> [/quote]

The null type is just a language gimmick to bypass strong typing.
It does not exist in the data model.

>> Null is never an integer,
>> even though C will convert null to 0 within an int context (by  
>> design).
> [quote "Java Language Specification Second Edition"]
> The null reference can always be cast to any reference type.
> [/quote]
> Consider a method:
> public void setAge(Integer age) - where I receive an age as null  
> reference.
> And a call:
> setAge((Integer)null) - where I pass null reference as Integer.

Again, language gimmicks to bypass strong typing.  They have no  
relevance
to JCR.  The fact that the symbol "null" can be converted to the data
value of zero in an integer context has no relevance to a data model.
What you passed is zero, not null.

>> Within a data model, there are no language references.  There is no
>> value of null within hierarchical data structures like JCR.  There is
>> merely the presence or absence of names.  That is why setting a
>> property value to null causes the property to be deleted, just like
>> it does in perl.  The only equivalent to null within JCR would be
>> a reference property with an empty string value, which is generally
>> considered to be an error.
> We are discussing "Content Repository for Java" not for Perl or C  
> so it is
> understandable that we will refer to Java Language Specification  
> for guidelines.
> And when I set a variable value to null Java will not delete the  
> variable
> neither make it not referenceable.

Variables don't exist in data models.  Please, try to think of it terms
of data that is exchanged between two different computers that have
no shared memory.  The language concepts that you are talking about
do not cross such a boundary and thus have no purpose in a data model.

> If we will discuss "Content Repository for Perl" I will not bring  
> this issue up, but for Java it is unexpected behavior, and as you  
> can see, many participants from this list agree with it.
>
>> All of the examples you have given are just unwise design.
> Could you please provide a `wise` design for optional date field  
> that should be stored in JCR. So we can use it to ease our pain.

Yes.  Make the date field an optional property.  If the property exists,
then the field is present.  If not, then the field is absent.

>> When you read XML that
>> contains default attribute values, the reader of the XML is  
>> responsible
>> for filling in the default for its data model when an attribute is
>> absent.  If you are using null to indicate data values then your
>> system is going to encounter a great deal of errors due to language
>> side-effects regarding the special meaning of null.  Null is special
>> specifically so that it won't be mistaken for any normal data value,
>> thereby allowing the language to indicate NPE instead of accidentally
>> dereferencing some arbitrary memory location.
> Somehow I am missing why would my application "encounter a great  
> deal of errors"
>
> Here is real-life use case from my application. I am parsing XML  
> that came from UI:
> <node name="contact" type="chd:document" uuid="62b16ab8-...">
>   <property name="name" type="String" multiple="false">
>     <value>John tester</value>
>   </property>
>   <property name="age" type="Integer" multiple="false">
>     <value/>
>   </property>
> </node>
>
> So my ContentHandler will do:
> Node node = root.addNode("contact", "chd:document");
> node.setProperty("name", valueFactory.createValue((String)"John  
> tester"));
> node.setProperty("age", valueFactory.createValue((Integer)null));
>
> So I don't see "great deal of errors" here.

Well, first, you haven't assigned the value null -- you just assigned
age a value of 0.  The XML is showing it as an empty string (an empty
element has value = "") and you translate that to null (for no apparent
reason), convert that to a data value of Integer 0, and then assign it
to age.  Writing that back out would be the same as if the value had
been given as <value>0</value>, which isn't the same thing unless we
assume application knowledge about infants not being in contacts.
There are at least two or three errors in that line alone.
A sane implementation would check the string value for
an integer and exclude the age property if the value is invalid.

There might be some argument for using null within the query
model as a synonym for "name doesn't exist".  For example, instead
of checking for both ((name doesn't exist) or (name == default)),
it might be faster to check for (name == (null or default)).
Allowing null as a property value would prevent such a language
feature from being used within the query model.

....Roy


Mime
View raw message