Export and Protected Scoping in Dynamic Libraries

Adam Wilson flyboynw at gmail.com
Wed Dec 14 11:41:15 PST 2011


Hello Everyone,

I want to start this conversation by pointing out that I come from a  
C/C++/C# background and my ideas and frustrations in this post will be  
colored by that history.

When I first approached D, the idea of an 'export' confused me. I've since  
figured out, at least in libraries, that in C# terms D's 'export' means  
'public'. However, this raise a problem, specifically, how do I export a  
protected member from a dynamic library?

Here is a table of D's scoping system mapped to C#'s scoping system as I  
understand it:

D		     C#	
export		public
public		internal
protected     internal protected
private	      private

I believe this illustrates the problem clearly. There is no protected  
scope that is available to the outside world. The ONLY way to export a  
function in D is to mark is as an export. I have tested this against 2.056  
and without the export identifier, the function never makes it into the  
.lib file. But Protected functions are clearly intended to be used outside  
of the library that they are built in. Currently, D says no; but without  
protected functions, inheritance becomes very troublesome. Any library of  
decent size is going to want to allow it's consumers to inherit from it at  
some point. For example, just yesterday I wrote four functions that  
overrode protected functions in .NET's WPF library. Without access to  
these protected functions I would have been simply unable to solve the  
problem. And my boss would have been VERY unhappy about that.

I think the way export should work is more like an attribute or note to  
the compiler that says "Hey Mr. Compiler, here is this public function,  
compile it. And while you're at it, I set this little flag over here that  
says you should export it as well." It would look something like 'export  
public' or 'export protected'.

So the new D->C# scope mapping table might look like this:

D		     		 C#	
export public		  public
public				 internal
export protected	protected
protected     		 internal protected
private	      		 private

This would completely solve the issue of protected scoping in dynamic  
libraries. As a note, 'export private' should be a compiler error.

I know there is a lot of resistance to making design changes to D2 at this  
point, and rightly so. The biggest issue I see here is that it breaks with  
TDPL. However, this is a major issue and one that will block many people  
 from picking up D for serious work. Support for inheritance from dynamic  
libraries is a MUST HAVE for dynamic libraries to be truly useful. As for  
maintaining backwards compatibility, a function with just 'export' could  
be easily mapped to 'export public' as that is it's current behavior.  
Also, please note that I am not married to that syntax. But a solution is  
required and I think that this one represents a good compromise. It  
doesn't introduce any new keywords, fixes a major design issue, and  
increases expressiveness and readability.

Any thoughts, objections, rants, raves? Walter, Andrei, thoughts?

-- 
Adam Wilson
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/


More information about the Digitalmars-d mailing list