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

Okay...


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

So what you are describing is a neo-wrapper, as opposed to a classic wrapper? I see different ways to employ a wrapper as opposed to a fundementally different technique.


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

FWIW, I am not chastising anybody - MS or you. Rather, I am pointing out that a term is being used incorrectly. As for MS, in the VFP documentation referring to subclassing activex controls, I see nothing wrong with that. The control itself and the container, for all intents and purposes, are the same. Therefore, if you are subclassing the container, you are effectively subclassing the control.

Creating a wrapper class is simply not the same thing. While you can simulate the end-result, that is not the issue. When VB programs simulate inheritance, it is not inheritance. When somebody simulates the raising of events through access/assign methods, they are not events.

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

Again, the issue is not what can be done. However, if I could subclass a COM Class, I could then elect to protect properties or change functionality by overriding inheritance. With subclassing, I rely on inheritance as the mechanisim that makes that possible. Wrapper classes achieve the results by adding a layer around the class.


If you look at this issue from the end result, you may ask "who cares"? If you look at it from the standpoint of the correct application of terms, then I think one should care. There are two basic techniques we are discussing here: subclassing and wrappers. Each are very different. Why one would choose to mix-match terms is beyond my comprehension.


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

I can use a COM Component directly. With an ActiveX control, you always use the container. Even if you think you are using the ActiveX control directly, it is hosted in a container. Simply put, wrappers and subclasses are not the same thing.

Believe what you want. Mix and match terms if you like. My goal was to correct and clarify. If you don't care, fine. At least the thread now corrects the record...

< JVP >