On Thu, Jul 25, 2013 at 4:08 PM, David Korn <[email protected]> wrote:
> cc: [email protected]
> Subject: Re: Re: [ast-developers] [RFE] var.__ to access the parent variable
> of a type or compound variable
> --------
>
>> On Mon, Jul 22, 2013 at 1:28 PM, Cedric Blancher
>> <[email protected]> wrote:
>> > 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
>>
>> Erm... I like the idea very very much because it solves a few things
>> with big variable trees and (performance) scalabilty...
>>
>> ... but the question is... can var.__ be implemented in a way which
>> avoids going through any name lookup ? My worry is that it won't save
>> much CPU time if it operates via name lookup (e.g. does the nval API
>> have a way to do a |np_getparentnode()| ?).
>>
>> ----
>>
>> Bye,
>> Roland
>>
>> --
>
>
> Currently compound variable do not contain a pointer to the parent
> so I see little advantable to adding var.__ since it would be slower
> than creating a name reference to the parent via
> ref=${var%.*}
That's not possible if var is a local compound variable in a function,
for example (redux from a production script, with var.__ tacked on):
function do_child_node
{
nameref r=$1
...
nameref parent=r.__ # how should this work with ref=${var%.*}?
...
}
function process_loop
{
compound state
compound -a state.data
...
compound state.data[x][y][z].in
...
do_child_node state.data[x][y][z].in
...
}
>
> However, if I change this and store a pointer to the parent, then
> using having a syntactical means of referencin it would be useful.
> Using __ removes the ability to have __ as a subvariable.
>
> Perhaps ${var..} could refer to the parent.
I agree with Cedric that var.__ is more consistent (in line with
_.var) and looks better. ${var..} doesn't feel right (no, not rational
argument) and you didn't explain how to access a parent of a parent,
i.e. var.__.__
The idea to allow overloading to replace var.__ with a compound
variable on demand has IMO merit too.
> David Korn
> [email protected]
> _______________________________________________
> ast-developers mailing list
> [email protected]
> http://lists.research.att.com/mailman/listinfo/ast-developers
Irek
_______________________________________________
ast-developers mailing list
[email protected]
http://lists.research.att.com/mailman/listinfo/ast-developers
