[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 197: Un-initializing BPEL variables
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
begin:vcard fn:Assaf Arkin n:Arkin;Assaf org:Intalio adr;dom:;;1000 Bridge Parkway Ste 210;Redwood City;CA;94065 email;internet:arkin@intalio.com title:Chief Architect tel;work:(650) 596-1800 x-mozilla-html:TRUE url:http://www.intalio.com version:2.1 end:vcard
S/MIME Cryptographic Signature
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]