Re: Shadowing of variables..

2011/11/28 Florent Georges <fgeorges@fgeorges.org>

> My pragmatic way of looking at it is that this prevents the compiler to
> detect what is most likely an error.


I guess that depends on your style of programming. If you prefer to rename
the variable at each step of the calculation, then it's most probably an
error, but then you would also surely get an XD0023: Undeclared variable
exception anyway, so it wouldn't go by unnoticed.

There's also debugging. Say I have this sequence of steps to calculate $var:

<p:variable name="var-tmp1" select="..."/>
<p:variable name="var-tmp2" select="big expression with multiple references
to $var-tmp1"/>
<p:variable name="var" select="big expression with multiple references to
$var-tmp2"/>

Now, if I suspect there's an error in the calculation of $var-tmp2, or for
any other reason I want to see what results I get if I skip that step, I
would have to go through the select expression for $var and replace
"$var-tmp2" with "$var-tmp1" throughout. And then, when I want to
reintroduce var-tmp2 again in the sequence of calculations, I would have to
remember to update the references in $var from $var-tmp1 to $var-tmp2 - and
the compiler would definitely not catch those errors if I forget it (could
possibly give a unused variable warning).

Also, maybe I want to add a couple of calculations inbetween var-tmp2 and
var (or split a calculation into multiple calculations); I would again have
to go through $var and change all the references.

On the other hand, if I could do this:

<p:variable name="var" select="..."/>
<p:variable name="var" select="big expression with multiple references to
$var"/>
<p:variable name="var" select="big expression with multiple references to
$var"/>

...then it would only be a matter of commenting out the second line - no
references to update.

Also keep in mind that we might start seeing code like this if the variable
needs to be in a different environment:

<p:variable name="var" select="..."/><p:group>
<p:variable name="var" select="..."/><p:group>
<p:variable name="var" select="..."/><p:group>
<p:variable name="var" select="..."/><p:group>
<p:variable name="var" select="..."/>
...do stuff with $var here...
</p:group></p:group></p:group></p:group>

...I might even do it myself to avoid bugs even though it's butt ugly.

Regards
Jostein

2011/11/28 Chris Maloney <voldrani@gmail.com>

> FWIW,
> I agree with Florent, and would vote against it.  Especially when
> considering newer programmers, or programmers who come from an imperative
> programming background, immutable variables (variables that don't vary) can
> be confusing.  Allowing them to redefine (shadow) an immutable variable
> just makes it all the more so.  I think enforcing each variable to have a
> unique name within the same scope would be in keeping with the nature of
> this programming paradyme, and would help to reduce bugs, and make bugs
> that do occur easier to find.
> Just my two cents.
> Cheers!
>
>
> On Mon, Nov 28, 2011 at 5:58 AM, Geert Josten <geert.josten@dayon.nl>wrote:
>
>> > > PS: what are the use cases for XSLT? ;-)
>> >
>> >   Honestly, I am not quite sure but I suspect this is the same
>> > reason.  Maybe also to ease generating code in some cases.  But
>> > I didn't say I liked it more in XSLT :-)
>>
>> Not how I meant it. It is just if this is common practice in XSLT people
>> could be used to this, and expect it to behave similarly in XProc. XQuery
>> allows doing similar things with let's as well, so why should XProc be
>> different? ;-)
>>
>> Cheers..
>>
>>
>