>>
>I know that wrapper classes are nothing new, but the idea of being able to create an 'invisible' wrapper class is.
><
>How can a wrapper be invisible?

If, after instanciating the wrapper, you are allowed 'unfettered' access to the wrapped object, whether or not the designer of the wrapper foresaw your need. If the syntax to manipulate the object directly or through this 'wrapper' is identical, than the wrapper can be said to be transparent.

>When you create a classic wrapper, you have to implement in your wrapper all functionality that you want to be reachable from the caller.
>
>Only if you elect to protect what you are wrapping.

That's how this technique is fundementally different than a classic wrapper. There is no need to protect or expose anything- it's all available, just as in a subclass. The only things you worry about are those you wish to force a change on.

>If it is not subclassing, it should not be called subclassing. Perpetuating the misapplication of terms leads to confusion. Subclassing in the OO world has a very precise definition. A wrapper may have a less precise definition, but still, is distinguishable from what subclassing is.

Are you also chastising MS for calling what VFP does with ActiveX controls subclassing? It seems that, at least as far as MS is concerned, the definition of subclassing isn't as precise as you would have us think. I haven't looked at cross-platform subclassing in .NET, but I bet that it uses a similar technique.

>Further, the same result is acheived only if you elected to have subclassing go that far. Subclassing, assuming you would take it to its limits, can stretch beyond what a simple wrapper can achieve.

Can you give an example of what subclassing a COM object can do that my technique cannot?

>In an ActiveX control scenario, what you are doing is subclassing a container. For all intents and purposes, the VFP activex container is transparent. No such animal exists for non-visual COM Components.

Of course it does. I just gave you that transparency. Your classic wrapper would force you to act on a property of the wrapper to access the wrapped object directly (oWrapper.oCommand.CommandText), where using the method I described, you can access the property directly (if the author chooses to allow it- oWrapper.CommandText) as if accessing the command object directly, and the calling code doesn't know if it's accessing a Command object, or a 'subclass' of the command object, because the calling syntax is identical.

>The fact that ActiveX controls are hosted in a container is a fundamental difference between ActiveX COntrols and Native Controls. Therefore, the container issue cannot be set aside.

Why not? If I drop a subclass of the WebBrowser control and use the property sheet to name that container "oIE", I can call methods of that control directly using "THISFORM.oIE.Navigate()"; I don't have to do something like "THISFORM.oIE.Control.Navigate". The fact that VFP uses a container object is just a means to the same end. Unless it knows to check for properties that are specific to a container object, the calling code would have no idea that what it is accessing is not the real McCoy.

> As for what subclassing is, I will take that as a rhetorical question as I am sure you know what the defintion is.

Actually, if you are contesting MS' use of the word in it's literature, I am not sure I know what the definition is. That's why I am asking for clarification.

>Why you go through the bother of an access method is beyond me. When you create an instance of the wrapper, an instance of of what the wrapper wraps should be created as well. In a simple example like this, access/assign methods only complicate the issue. What real utility do they provide? More to the point, if a wrapper just acts as a pass-through, why bother?

Without the THIS_Access method, how else would you be able to access the wrapped object as if you were accessing the object itself? If I use this technique to wrap a COM object and want to retrofit all of my code that uses the object to use the 'subclass' instead, all I have to do is change the CREATEOBJECT line to use the class name instead of the ProgID. No other code will break. This is the exact same as if I had created a subclass. You can't say that about a classic wrapper class.

>Using the technique I described, you _can_ override and change behavior. Did you read the entire post?
><
>No.. What your wrapper class does is pre-process data before relying on the default behavior of the XMLDOM instance. In your example, 2 calls are being made. The first to your class's loadxml method and the second to the XMLDOM's loadxml method. If there was only one call, I would be inclined to agree with you. Wrappers are good for pre/post processing.

I changed the behavior of the call by adding functionality before calling the default code. This is exactly like adding code to a subclass' method and then calling DODEFAULT(). (Which is two calls as well). I could have left out the call to the DOM object, and called it 'overriding' (one call).

If your classic wrapper exposes the wrapped object via a property object reference, you have no control over which properties and methods of the wrapped object the caller has access to, and so cannot 'override' anything.

I don't see what the functional difference is.

>Ultimately however, they don't change underlying functionality. Rather, they augment the data prior to invoking the default behavior or change the by-product of the default behavior. If you want to change the default behavior, that is what subclassing is for.

See above. I can augment _or_ override.