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()| ?).
>
> Currently compound variable do not contain a pointer to the parent
How hard would it be to add such a pointer?
> so I see little advantable to adding var.__ since it would be slower
> than creating a name reference to the parent via
> ref=${var%.*}
Erm... that's not true in the case that "var" is a nameref to a local
variable in a different scope. In that case you don't have access to
anything below the point referenced by "var".
The other issue is that "var.__" would IMO make any scripts which
operate on variable trees much _cleaner_. Right now getting it right
can be very very messy.
> 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.
Erm... that's not true (see "_Bool" as precedent... it doesn't
interfer with existing production scripts either) ... as Cedric said
varname.__ could reference the parent of a compound variable as long
it's not set... which renders the concern more or less invalid for
compound variables. User-defined types (e.g. $ typeset -T ... #) could
simply forbid the declaration of a member variable with the name "__".
Erm... and which script author names a variable "varname.__" anyway
(plain "__" without any further description ?) ? =:-)
> Perhaps ${var..} could refer to the parent.
I really really dislike "var.." ... and it raises the question how to
access further levels (e.g. parent of a parent or parent of an parent
of an parent) easily.
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [email protected]
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
_______________________________________________
ast-developers mailing list
[email protected]
http://lists.research.att.com/mailman/listinfo/ast-developers
