I don't know about Karsten, but the reason I have a knee-jerk reaction 
against suffixes like "Wrapper" is that it just feels like cruft, based 
on other systems where the word had no consistent meaning, at least from 
a user's perspective, it just seemed a hack to extend an API or 
facilitate its use without changing the deeper classes, or it was in 
fact an implementation detail that just happened to be exposed to the 

It's another naming issue I guess.  Call it a Handle and use an "H" 
suffix. Or an Accessor.   Call it a "Lever", I don't know :) "Wrapper" 
just has bad connotations to some of us :)  (Maybe like "Component")  In 
the end it will just be something that a C++ user has to learn what it 
means, but at first glance they have to have trust that it's actually 
very useful and that there's a good reason they have to do that extra 


Peter Amstutz wrote:
> On Thu, Dec 06, 2007 at 05:50:04PM +0100, Karsten Otto wrote:
> My concern is that if the wrapper class is named with just the name 
> stem, the following situation is very confusing:
> {
>   Vobject* foo = getFoo();
>   delete foo;
>   // Oops.  I think I deleted foo, but all I did was delete
>   // the wrapper.  The underlying object is actually still there.
> }
> {
>   VobjectWrapper* foo;
>   delete foo;
>   // I know it is a wrapper, so I know I'm just deleting the wrapper
>   // and that the underlying object is untouched.
> }
> This is a little contrived, since wrappers are usually stack-allocated 
> (although the confusion is still there, just not as obvious), but 
> similar cases can be made for other common operations such as assignment 
> and comparison.
> It's ugly, but it should be considered an artifact of the 
> implementation.  Languages with better metaprogramming facilities (meta 
> object protocols, in the traditional academic sense) and hopefully 
> script language bindings should not require this technique.

vos-d mailing list

Reply via email to