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? _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
