TDPL: Manual invocation of destructor

[Michel Fortin]

On 2010-08-10 12:35:10 -0400, "Steven Schveighoffer" 
<schveiguy at yahoo.com> said:

> It's not the same function, just the same name.  Though I can see how 
> it  might be confusing:
> 
> container.clear(); // ok to reuse container
> clear(container); // not ok to reuse.
> 
> But hopefully syntax highlighting can help make this distinction.  It 
> was  kind of nice that delete was a keyword, at least you couldn't 
> confuse it  with anything else.

Syntax highlighting... You want an IDE flagging dangerous functions in 
red? Not a bad idea actually.


> Again, clear doesn't scream out "use me on everything!" It's a 
> dangerous  function and should be treated as such.  This seems solvable 
> via  documentation.

In my world, we add safeties to make dangerous things less dangerous. A 
typical microwave oven will refuse to start if you don't close the 
door. The documentation is there to tell you what not to do, but we 
don't rely solely on documentation.

People will always do stupid things, sometime by accident. It's 
especially easy to make the accident of writing clear(a) instead of 
a.clear() in my opinion. Think of this scenario:

	Employee:     Hey boss, how do I empty a container?
	Boss (busy):  clear()
	Employee:     Thanks!


> I'd rather have a compile-time solution than a runtime  solution if at all.

Me too.

And the solution is so simple: clearable classes and structs implement 
the clear() function. Non-clearable classes and structs do not. The 
only problem is that it goes against Andrei's book.


> Are Objective-C bindings structs or classes?  If they  are structs, we 
> may be able to have clear obey some sort of enum, although  that seems 
> like an ugly solution.

They're classes.


> Anyone who's learned C and C++ knows that you use the destruction 
> method  that matches with the construction method.  This is kind of the 
> same  thing, you wouldn't expect someone to allocate an Objective-C 
> resource via  some non-D-standard function, and then use a D-standard 
> function to  deallocate.  I think the programmer has a responsibility 
> to obey the rules  of allocation/deallocation.

You're misunderstanding the purpose of the bridge, which is to make 
things transparent for the user.

The D/Objective-C bridge in its current incarnation allow you to pass D 
objects on the Objective-C side as if they were Objective-C objects, 
and to treat Objective-C objects in D code as if they were D objects. 
The wrapping/unwrapping is done on the fly, making this mostly 
transparent to the user.

It's done that way so you can use the Cocoa framework, which wouldn't 
be very usable without an easy way to subclass Objective-C classes and 
move object instances around.


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/