Not arguing against it, but then I'm not arguing against macro expansion, either. It has been used with great success for quite awhile and there are things that can make it more readable. As long as you don't go overboard with it, there's no real disadvantage, IMHO (assuming it's not in a loop, where the slower speed vs. named expressions, which I also use, does not come into play).

And just my two cents, "properly formatted local variables" are not more readable, they are less readable.

>>VFP 9 help says "Returns the current value for a property or program code for an event or method at design time" and says the return value is "Character, Currency, Date, DateTime, Numeric, or Logical." So it's not obvious - and, technically, not documented - that you can get an object reference. And, for instance, a container is not a property of a form, it would be an object placed on a form and a property of the container would be something like cnt.Width.
>
>OTOH, the function which gets PEMs into an array is called aMembers(), not aPEMs, and it gives you various PEMs and member objects.
>
>So while the help is inconsistent there, the predecessor of GetPem() function has returned objects before... well, at least their names, along with other properties.
>
>To me, getPem() returning an object is equally non-obvious as a cryptic macro expansion. And if we assign this object to a properly prefixed local variable, it's even more readable than a macro or an eval() call.
>
>But then, de gustibus non est disputandum.