>Funny thing is that, not too long ago during a self-imposed review, I had a problem understanding my own design due to the exact issue Mike was refering to. When designing a framework, that is a red flag.

I won't even admit how often that happens to me. Some of it, I chalk up to age, rather than solely bad design. <s>

>>Aside: The reason we got close to this in the first place is because of not being able to bind to methods where strings are passed by reference in VFP. This was a potential deal-breaker for some heavy text processing we were doing, so we've reverted to creating a token Empty object as the payload, and simply adding a few simple properties to pass around. This is much like the object in Mike's example. And it turns out to be a very flexible design when you suddenly want to add new features.
>
>Yes. The challenge with all of this stuff is always in the design. Sometimes I'm amazed how a simple design change can open up a whole new world.

Exactly. In our case we had a framework that involved a bunch of text processing. The text itself was passed around by reference, primarily for performance reasons because only a fraction of objects would choose to operate on any specific text block. This was all fine until we looked into event binding options after VFP 8 hit the scene.

It seemed ironic that you couldn't bind to a method where parameters were passed by reference, but you could bind to them if the parameters were object *references*. In any case, by switching from an lcText string parameter, to a token object with a cString property, event binding became open to us, while still retaining the pass-by-reference performance.

But that's only the beginning. Say, for example, you wanted to add a feature that gives the bound objects the option to disable further processing. Simple--just add an lDisabled property to the token object, and add a few lines to your framework that honor that flag. Next, say you want to employ a "QC observer" object that watches a sequential process and makes notes along the way. Simple again--just let that object ADDPROPERTY() to the token, which allows it (the QC object) to remain stateless, while at the same time none of the rest of the design requires any changes at all.

These things all start to seem easier--more flexible, more maintainable--when you head down this path, and I'm liking it (so far).

Regards,

-- Randy