Forwarding the proposal. Wendy's idea to use varname.__ as name to reference a compound/type variable's parent is IMO *great*.
For example: compound c1=( compound c2=( integer i=5 ) ) nameref ni=c1.c2.i # reference i nameref nc2=ni.__ # accesses c2 though i nameref nc1=ni.__.__ # accesses c1 through i Ced ---------- Forwarded message ---------- From: Cedric Blancher <[email protected]> Date: 22 July 2013 13:25 Subject: Re: [ast-users] _ doesn't refer to the correct object. To: Wendy Lin <[email protected]> Cc: Dan Douglas <[email protected]>, David Korn <[email protected]>, [email protected] On 22 July 2013 12:58, Wendy Lin <[email protected]> wrote: > On 22 July 2013 12:06, Cedric Blancher <[email protected]> wrote: >> On 22 July 2013 11:53, Dan Douglas <[email protected]> wrote: >>> On Monday, July 22, 2013 11:08:35 AM Irek Szczesniak wrote: >>>> On Mon, Jul 22, 2013 at 11:00 AM, Dan Douglas <[email protected]> wrote: >>>> > In this type, I can't think of any way to refer to "obj" from within >>>> > "x.get". >>>> > _ should point to "obj" in this context, not "obj.x". >>>> > >>>> > #!/usr/bin/env ksh >>>> > >>>> > typeset -T Type=( >>>> > typeset -h 'This will be a property.' x >>>> > integer -h 'This will be the backing field for x.' y=5 >>>> > >>>> > function x.get { >>>> > # Huge problem here because _ refers to x, >>>> > # we can't access anything. >>>> > ((.sh.value = ++_.y)) >>>> >>>> This can't work. .sh.value is identical to _ >>>> >>>> Think about ksh93 types as compound variables with predefined >>>> discipline functions. In your example you're trying to assign the >>>> value of ++_.y to the value of a compound variable - which obviously >>>> cannot work. >>>> >>>> Irek >>> >>> I don't know, it doesn't make sense to me for disciplines within types that >>> hook the fields of the type. I think _ should be different here than for a >>> bare discipline defined in the global scope. Those don't have to care about >>> which instance they are a part of. >>> >>> The only workarounds I can think of are nasty, like: >>> nameref this=${.sh.name%.*}; .sh.value=${this.y}; >> >> Oh, I got it. What we need is a way to access the parent of a >> variable, like cd .. accesses the parent directory. _... obviously >> won't work. >> >> What about _._ to access the parent in both types and compound variable >> trees? >> >> >> For example: >> >> compound c1=( compound c2=( integer i=5 ) ) >> nameref n1=c1.c2.i >> nameref nc2=i._ # accesses c2 though i >> nameref nc1=i._._ # accesses c1 through i > > That example doesn't work. AFAIK you want s/i./n1./ Yes, you're right. > > IMO this would be better: Please follow the Unix philosophy and use __ > (two _) for the parent: > compound c1=( compound c2=( integer i=5 ) ) > nameref ni=c1.c2.i > nameref nc2=ni.__ # accesses c2 though i > nameref nc1=ni.__.__ # accesses c1 through i That proposal is *much* better. +1 for '__' (double '_'), analogous to '..' to access the parent directory. Ced -- Cedric Blancher <[email protected]> Institute Pasteur -- Cedric Blancher <[email protected]> Institute Pasteur _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
