Difference between revisions of "DIP45"
(→Description) |
(→Rationale) |
||
| Line 41: | Line 41: | ||
==Rationale== | ==Rationale== | ||
| − | + | ===Turning export into an attribute=== | |
| + | |||
| + | Currently the export protection level is the highest level of visibility. This however does not allow exporting protected members. Exported protected members is neccessary sometimes though. | ||
| + | Consider the following example. | ||
| + | |||
| + | <syntaxhighlight lang=D> | ||
| + | module sharedLib; | ||
| + | |||
| + | class Base | ||
| + | { | ||
| + | protected final void DoSomething() { ... } | ||
| + | |||
| + | public void func() | ||
| + | { | ||
| + | DoSomething(); | ||
| + | } | ||
| + | } | ||
| + | </syntaxhighlight> | ||
| + | |||
| + | |||
| + | <syntaxhighlight lang=D> | ||
| + | module executable; | ||
| + | import sharedLib; | ||
| + | |||
| + | class Derived | ||
| + | { | ||
| + | protected final void DoSomethingAdditional() { ... } | ||
| + | |||
| + | public ovveride void func() | ||
| + | { | ||
| + | DoSomething(); | ||
| + | DoSomethingAdditional(); | ||
| + | } | ||
| + | } | ||
| + | </syntaxhighlight> | ||
| + | |||
| + | In the above example 'DoSomething' should only be visible to derived classes but should still be exported from a shared library. This does not work with the current implementation of 'export'. Turning 'export' into an attribute will make this work. | ||
==Implementation Details== | ==Implementation Details== | ||
Revision as of 09:07, 1 September 2013
| Title: | making export an attribute |
|---|---|
| DIP: | 45 |
| Version: | 1 |
| Status: | Draft |
| Created: | 2013-08-27 |
| Last Modified: | 2013-08-30 |
| Author: | Benjamin Thaut |
| Links: | http://forum.dlang.org/post/5112D61B.5010905@digitalmars.com
http://forum.dlang.org/post/kvhu2c$2ikq$1@digitalmars.com http://d.puremagic.com/issues/show_bug.cgi?id=9816 |
Contents
Abstract
Export and its behavior needs to be changed in serveral ways to make it work on Windows and allow better code generation for other plattforms. The Rationale section explains the problem and shows how this DIP solves it.
Description
- The 'export' protection level should be turned into a 'export' attribute.
- If a module contains a single symbol annotated with the 'export' attribute all compiler internal symbols of this module should recieve the 'export' attribute too (e.g. module info).
- If a class is annotated with the 'export' attribute, all of its public and protected functions and members will automatically recieve the 'export' attribute. Also all its hidden compiler specific symbols will recieve the 'export' attribute.
- It should be possible to access TLS variables across DLL / shared library boundaries.
- On *nix systems default symbol visibility is changed to hidden, and only with export marked symbols are visible.
Rationale
Turning export into an attribute
Currently the export protection level is the highest level of visibility. This however does not allow exporting protected members. Exported protected members is neccessary sometimes though. Consider the following example.
module sharedLib;
class Base
{
protected final void DoSomething() { ... }
public void func()
{
DoSomething();
}
}
module executable;
import sharedLib;
class Derived
{
protected final void DoSomethingAdditional() { ... }
public ovveride void func()
{
DoSomething();
DoSomethingAdditional();
}
}
In the above example 'DoSomething' should only be visible to derived classes but should still be exported from a shared library. This does not work with the current implementation of 'export'. Turning 'export' into an attribute will make this work.
Implementation Details
Work in progress
Copyright
This document has been placed in the Public Domain.
