On 25 July 2013 16:08, 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%.*}
>
> 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.
Why?
Remember the concept of overloading?
As long no variable var.__ is defined var.__ refers to the parent
compound variable or array node. If var.__ is declared, for example
using compound var.__=(...), then this counts as overloading the
var.__ reference with a real variable. I don't see a problem there.
>
> Perhaps ${var..} could refer to the parent.
WTF? David, please don't do that to ksh93. I think everyone here has
agreed that var.__ is a beautiful construct, an extension of _ which
is an analogue to C++ this. You didn't choose var.. or var. for ksh's
this reference, right? Why? Because it's gross ugly.
Ced
--
Cedric Blancher <[email protected]>
Institute Pasteur
_______________________________________________
ast-developers mailing list
[email protected]
http://lists.research.att.com/mailman/listinfo/ast-developers
