Alex,
Thank you for the reply.
It is fine with me if you and other TC memebers agree with
my answers. (And it seems you do.)
At this moment I have no intention to propose modifying
the variable initialization behavior.
Yuzo
Alex Yiu wrote:
>
> Hi Yuzo,
>
> I also think the answers to both cases are uninitializedFault.
>
> Resolution of variable "v1" should point to the declaration in the local
> scope. If we allow "v1" refers to the value of "v1" in the outter scope,
> it would be quite confusing in terms of scope modularization.
>
> If a local scope really want to reuse the value of "v1" from the outter
> scope, one would not declare a local variable with the same name "v1".
>
> I understand the motivation and usage patterns behind these questions.
> But, as of this moment, "scope" in BPEL is not exactly designed for
> those patterns.
>
>
>
> Regards,
> Alex Yiu
>
>
> Yuzo Fujishima wrote:
>
>> Hi,
>>
>> I have a few questions about variable initialization and
>> variable name hiding. Although I have my answers to them,
>> I would like to know what you think because they are somewhat
>> counter-intuitive in my opinion.
>>
>> Case 1:
>>
>> Description:
>>
>> scope S1
>> variable v1=101
>> scope S2
>> variable v2=v1
>> variable v1=201
>>
>> Is this legal?
>> If legal, will v2 be 101 or 201?
>>
>> My answer:
>>
>> As per 9.1 Variables,
>>
>> variable v2=v1
>> variable v1=201
>>
>> should be conceptually equivalent to
>>
>> variable v2
>> variable v1
>> sequence
>> assign v1 -> v2
>> assign 201 -> v1
>>
>> Therefore, an uninitializedVariable (v1) fault
>> should be raised.
>>
>> Case 2:
>>
>> Description:
>>
>> scope S1
>> variable v1=101
>> scope S2
>> variable v1=v1
>>
>> Is this legal?
>> Will an uninitializedFault be raised?
>>
>> My answer:
>>
>> As per 9.1 Variables,
>>
>> variable v1=v1
>>
>> should be conceptually equivalent to
>>
>> variable v1
>> sequence
>> assign v1 -> v1
>>
>> Therefore, an uninitializedVariable (v1) fault
>> should be raised.
>>
>>
>> Yuzo Fujishima
>> NEC Corporation
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail. You may a link to this group and all your TCs in
>> OASIS
>> at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
>
>
>
>
