>
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?

<
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.

<
IOW, if you want to call a "Execute" method in a classic wrapper, you have to create an execute method that receives all the parameters that the method in the wrapped object does, and pass them through to the 'wrapped' object.
>

Again, this is only true if you elect to protect what you are wrapping.


>
I also know that the technique I described is not really subclassing, but it nets the same result, and the caller wouldn't know the difference, because the calling syntax is the same as if you had subclassed the control.
>

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.

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.


>
Fine, if MS can take the liberty of calling it 'subclassing' the ActiveX control, I don't think it would be that far out of line for me to do so.
>

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. The two scenarios are easily distinguishable from one another. Therefore, to rationalize the use of the word subclass in the non-visual COM Component scenario because the word subclass is appropriate in an visual activeX control scenario is both illogical and devoid of merit. In other words, it does not make sense.


>BTW, what is subclassing? Care to describe the technical and functional difference between what VFP does with native controls, and what it does with ActiveX controls (Container issue aside)? And the functional difference between this and what will be possible in VS.NET?
>

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. As for what subclassing is, I will take that as a rhetorical question as I am sure you know what the defintion is. As for .Net, I don't see where that is relevant to this discussion - and therefore will not comment on that - except to say that my previous comment on ADO.Net should suffice as a good explanation of the fundamental difference.


>
The object using the THIS_Access method is _not_ just a wrapper class. Curious-do your DataClas wrapper objects allow you to directly access properties like Dialect and CommandStream? My guess is no, because you would have had to specifically implement those properties in your class, and put code in place to transfer the values to the real Command object.
>

DataClass COM does not allow unfettered access to PEM's. I looked at your sample. As you said:

"The object below is a simple wrapper around the Microsoft XML parser. All it does 'change' a couple of default properties in the DOM object, and ensure that any XML passed to the LoadXML method starts with ''."

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?


>
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.

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.

< JVP >