On Mon, Jul 22, 2013 at 7:05 PM, Dan Shelton <[email protected]> wrote: > On 22 July 2013 15:11, Lionel Cons <[email protected]> wrote: >> On 22 July 2013 14:15, Dan Douglas <[email protected]> wrote: >>> On Monday, July 22, 2013 01:28:21 PM Cedric Blancher wrote: >>>> Forwarding the proposal. Wendy's idea to use varname.__ as name to >>>> reference a compound/type variable's parent is IMO *great*. >>> >>> In the general case of compounds it's fine. In the case of objects created >>> from user-defined types, it's far better and customary to have a reference >>> to >>> the object, and then refer to sub-variables relative to that (from the >>> outside >>> in, not from the inside working out.). >> >> I think it still has merit for both cases. But IMO it should help with >> the major issue that building large trees inside a compound variable >> where a single compound variable at the base contains a compound >> variable array, which itself harbours many more nesting levels of >> compound variables. >> >> The current performance of such a construct SUCKS compared to java or >> python (or compared to a real Unix filesystem), regardless of the >> cache David has implemented, because constructing and using such a >> tree always requires the absolute variable name. >> Using the Wendy/Cedric proposal of nameref parent=varname.__ to >> reference the parent compound or type variable is a very good way to >> (finally) introduce relative variable names top build and access >> variable trees. > > I like that idea too. It's in the spirit of Unix and removes the need > to remember the full name of the variable each time we navigate around > in a variable tree. > > David, how hard would it be to implement a varname.__ prototype for > the next alpha release?
David, what do you think? Irek _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
