Hi Erik,

I don't know about great, but I'm the other mind, the one that posted the same idea on the wiki a while back.

I just found this thread today [finally coughed up the $ for UTPM so I can actually navigate this board now :)]

I've been using Thus_Access decorators in production for about 8 months now and love 'em. You've got to weigh the reduced code line-count with the cost of the This_access firing EVERY time you touch the object. If performance is key, hand-coding the pass-through code with _Access and _Assign is faster.

And I'll add that there is a bit of a "gotcha" lurking with using these fellows vis a vis WITH/ENDWITH constructs. I'm going to stick my neck out and say this is a bug in vfp, but one could argue that it is just an inconsistency I guess.

Try the following code with VFP 6 and VFP 7 if you have it. The results are different and weird in both cases.

clear

o= CREATE("WithTest")

? "------- DOT ----------"
o.prop1="Hi"
? o.Prop1
o.SomeMethod()
?
? "------- WITH ----------"

WITH o
.prop1="Howareya?"
? .Prop1
.SomeMethod()
ENDWITH

DEFINE CLASS WithTest as RELATION

Prop1 = ''

FUNCTION THIS_ACCESS( tMember)
? "THIS_ACCESS: "+tMember
RETURN THIS

FUNCTION Prop1_ASSIGN( tvValue)
? "Prop1_ASSIGN: "+tvValue
This.prop1= tvValue

FUNCTION Prop1_ACCESS
? "Prop1_ACCESS"
RETURN This.Prop1

FUNCTION SomeMethod()
? "SomeMethod is fired"

ENDDEFINE


Another result, probably related, is the fact that you can GATHER NAME an object with Prop_Access methods to the underlying properties, but no go with THIS_ACCESS.

Just though I'd add this for the record here.

Ever considered simulating multiple inheritance by aggregating more than one object and placing a CASE statement in the THIS_ACCESS method? That could get interesting....

-lc