Export and Protected Scoping in Dynamic Libraries

[deadalnix]

Le 14/12/2011 20:41, Adam Wilson a écrit :
> 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?
>

The same goes for private virtual methods actually. They cannot be 
called, but they can be reimplemented in subclasses.

If you put that detail asside, this is a neat idea. I'd love to see that 
in D.