Yaron Y. Goland wrote:
> Bringing this back to 197, in the case of a complex type or element
> type we could treat this as a delete which, given that the entire
> contents of the variable is being deleted, would translate into an
> uninitialized value. Note however that this means making null and
> uninitialized effectively the same at the variable level. For example,
> imaging having a complex type variable that can contain 0 to 5 <foo>
> elements. Having no <foo> elements is legal and meaningful. So how
> exactly do we create a complex type variable that is empty but not
> uninitialized? I can't escape the thought that this is perhaps an edge
> case not worth covering?
In my opinion, having an empty complex type is not an edge case, and
forcing it to be un-initialized introduces complexity (no pun intended).
Let's say that I use a complex type to hold a list of items (0..n of
<foo>), which I believe is a common use case. Before I can do anything,
the variable needs to be initialized, so there's some activity (or set
of) that put items into the variable. It's possible that these
activities will put 2 items, or 5 items, or even no items. I cannot
determine the count a priori.
If putting no-items in the variable simply means it's empty (the way we
treat arrays and sets in other language), then anything pans out nicely.
I can iterate over the child elements of the complex type and do
something with each element; if the variable is empty then I have zero
iterations. Or if I worry about the case where n=0, I can always check
it with a simple expression. And, of course, I can put the value into a
message and send it to a service that accepts an empty set.
If putting no-items in the variable means the variable is
un-initialized, then now I have to worry about selection faults.
Attempting to iterate over the variable will cause a selection fault;
checking to make sure there are some elements will throw a selection
fault; trying to send that value will throw a selection fault. So I need
all those fault handlers to handle the empty value.
For me simple reads:
1. Take source value, assign it to target variable.
2. Empty is just another form of content.
3. If the target can accept the value, assign it*. Otherwise throw a fault.
4. To un-initialize a variable, use a specific operation that
un-initializes it.
* The empty value needs to be type-checked like any other value, before
assigning to a simple or complex type.
The only thing we know for sure is that empty cannot be assigned to an
element. But even that is not a special case. Imagine an expression of
the form '$foos/foo' with the target being an element of type foo. If
the expression selects one element, the assignment works. If the
expression selects any other number of elements, the assignment faults.
Why should the case for n=0 be different from n>1?
Assaf
