[Dev] removed use of defaultValue in parcel XML

[John Anderson]

One other snag I just noticed when switching from defaultValue to 
initialValue: If you ask if the item has an attribute you'll get yes if 
the attribute has an initialValue and no if it has a defaultValue. This 
is why changing from defaultValue to initialValue caused all the menus 
to not get displayed after I checked it in -- and another reason why 
having both defaultValue and initialValue as they are currently 
implemented seems too complicated/error prone.

John

John Anderson wrote:

> As the largest user of defaultValue in parcel XML, I decide to stop 
> using them for the reasons outlined below. While I was at it I removed 
> them in all the parcel XML. The change had no impact on startup time 
> (1:04 without a repository) (0:13 with a repository)
>
> John
>
> P.S. I noticed one semantic difference between defaultValue and 
> initialValue. A string attribute can have a default value of None and 
> an initial value can't
>
> Katie Capps Parlante wrote:
>
>> Hi all,
>>
>> We discussed initialValue and defaultValue back at the data model 
>> meeting in March: 
>> http://wiki.osafoundation.org/twiki/bin/view/Journal/DataModelMeeting20040311 
>>
>>
>> In particular, the apps team argued that the client of the repository 
>> (in this case, the application blocks code and content model) usually 
>> wants the value to be able to show up in queries, and wants to be 
>> able to modify the value if it is a mutable type (without modifying 
>> some shared value). We agreed that the apps team would use 
>> initialValue, and basically ignore defaultValue.
>>
>> I would argue that the client always wants the semantics of 
>> initialValue. One could imagine an optimization to initialValue, 
>> where a shared value is used until write (the item would get a copy 
>> in this case). Having two options with slightly different semantics 
>> is confusing, so I'd recommend that we don't expose defaultValue, and 
>> go ahead and make it an error in the parcel xml. If we find ourselves 
>> regretting this, we can always change it back.
>>
>> Cheers,
>> Katie
>>
>> John Anderson wrote:
>>
>>>
>>>
>>> Andi Vajda wrote:
>>>
>>>>
>>>> This proposal is a slippery slope, isn't it ?
>>>
>>>
>>>
>>>
>>> I'm a little confused why it's a slippery slope.
>>>
>>> In the past because of Katie's concerns, we agreed to use 
>>> initialValue instead of defautValue. I started using defaultValue 
>>> because it seemed more efficient, but evetually got bitten by 
>>> problems, which were the same problems Katie originally articulated 
>>> -- which I didn't fully understand. It seems like any benefits of 
>>> the current model don't out weigh the costs in complexity, so it 
>>> seems prudent to make sure nobody else falls into the same trap I did.
>>>
>>> John
>>>
>>>>
>>>> Andi..
>>>>
>>>> On Sun, 18 Jul 2004, John Anderson wrote:
>>>>
>>>>> So Andi didn't go for getting rid of DefaultValue. Morgen, can we 
>>>>> make it an error to use it in parcel XML?
>>>>>
>>>>> John
>>>>>
>>>>> Andi Vajda wrote:
>>>>>
>>>>>>
>>>>>>> As Andi notes below, if you modify an attribute with a default 
>>>>>>> value, and it's a mutable type, it will modify all items instead 
>>>>>>> of just this one item. This seems completely nuts -- and so 
>>>>>>> error prone that I can't ever imagine
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Well, you're re-phrasing this in a way that's not fair. No items 
>>>>>> are modified. Modifying a mutable defaultValue would make the 
>>>>>> value appear modified by all items that cause it to be returned 
>>>>>> but no items are actually modified since no item actually stores 
>>>>>> the defaultValue, except for the schema Attribute item.
>>>>>>
>>>>>> That's why the defaultValues of mutable type are marked readOnly, 
>>>>>> to prevent this very error from happening. The attribute is *not* 
>>>>>> marked readOnly, the actual mutable value is.
>>>>>>
>>>>>>> wanting to use it. As Katie pointed out to me there really isn't 
>>>>>>> a reason for both defaultValues and initialValues, except for an 
>>>>>>> optimization -- which the repository should hide from us anyway 
>>>>>>> and not expose as an api. So I propose
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> There is a semantic difference between defaultValue and 
>>>>>> initialValue that can be presented as such:
>>>>>>   - defaultValue prevents an AttributeError from being raised by 
>>>>>> returning a
>>>>>>     default value instead, owned by the schema
>>>>>>   - defaultValue really doesn't define an item's attribute value 
>>>>>> but a
>>>>>>     stand-in. I don't expect queries to return matched on 
>>>>>> defaultValues, for
>>>>>>     example. (Although it would be possible to do so, of course).
>>>>>>   - initialValue is a value copied into the item upon 
>>>>>> construction and that
>>>>>>     copy is owned by the item
>>>>>>
>>>>>> There is also the space/performance trade-off. It is not an 
>>>>>> optimization issue
>>>>>> really, as defaultValue uses less space but takes longer to 
>>>>>> access (everytime, the defaultValue is fetched from schema), 
>>>>>> whereas initialValue uses more space but takes less time to 
>>>>>> access since the value is copied into the item upon creation. I 
>>>>>> should also point out, that liberal use of initialValue 
>>>>>> everywhere will slow down item creation and item commits as these 
>>>>>> values have to be written out upon save.
>>>>>>
>>>>>>> that we remove defaultValues from the repostory. And if Andi 
>>>>>>> doesn't go for it, perhaps Morgen could make the parcel loader 
>>>>>>> treat defaultValue as an error.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Which one you use depends on your usage patterns. For non mutable 
>>>>>> types, the choice is really simple. For mutable types, again, the 
>>>>>> choice should be simple too as the data model protects the 
>>>>>> values. If you know the attribute is not going to change, 
>>>>>> defaultValue should do. If you want queries to match on the 
>>>>>> values, then defaultValue is not a good choice. So, there are a 
>>>>>> number of decisions you could be making.
>>>>>>
>>>>>> If you don't want to use defaultValue, don't use it. If you can't 
>>>>>> imagine ever using defaultValue, then don't; asking everyone else 
>>>>>> not to, or worse, preventing everyone else from using it is a 
>>>>>> little iffy.
>>>>>> I use it in the core schema and it works quite well.
>>>>>>
>>>>>> Again, there is no danger in using defaultValue, mutable values 
>>>>>> are marked readOnly by the data model, so changing a defaultValue 
>>>>>> is rather complicated and shouldn't happen by acciddent.
>>>>>>
>>>>>> There are semantic differences that should determine which one 
>>>>>> you want to use.
>>>>>>
>>>>>> Andi..
>>>>>>
>>>>>
>>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev