Extended Package Protection in D

posted in D Bits
Published March 03, 2016
Advertisement

Since the D1 days, D has had a package protection attribute akin to Java's (though unlike Java, it is not the default). Applying package protection to any symbol in a module makes it accessible only to modules in the same package.[code=nocode:0]module mylib.mypackage.mymodule;package struct MyStruct {...}class MyClass { package void doSomething() {...}}


Given the above, MyStruct is only usable and the member function doSomething in MyClass only callable directly inside the mylib.mypackage package. However, neither is accessible in any subpackages of mypackage (such as in a module mylib.mypackage.subpack.somemodule).


There was some demand for expanding the scope of package protection, so it was eventually added to the language. The above code still works as it always had, restricting access exclusively to the package in which a symbol is declared. Now, it's possible to do something like this:[code=nocode:0]module mylib.mypackage.mymodule;package(mylib) MyStruct { ... }class MyClass { package(mylib.mypackage) void doSomething() {...}}


In this snippet, MyStruct is accessible in the mylib package and all of its subpackages. The doSomething member function of MyClass is callable in mylib.mypackage and all of its subpackages. In effect, specifying a package name with the attribute tells the compiler the topmost package in which a symbol should be accessible, making it accessible also to all subpackages of that package.


This isn't an earth shattering feature, but it allows much more freedom for code organization. Consider a renderer package for a 2D or 3D game engine. One possible approach to supporting multiple renderers is to have a base engine.gfx package which contains the interfaces and an engine.gfx.impl package for all of the implementations (e.g. engine.gfx.impl.ogl). The extended package protection comes in handy here to make common internal declarations visible to the implementations while hiding them from the outside world:[code=nocode:0]module engine.gfx.common;package(engine.gfx):enum internalConstant = 123;struct InternalStruct { ... }void internalFunction() { ... }


Previously, you might put this module in the engine.gfx.impl package, make everything public, and tell users not to import anything in the impl package as a form of voluntary protection. Now, you don't even need a 'common' module. You can put each declaration where it makes sense to put it and the compiler will enforce your protection scheme for you.
Previous Entry My New Book: Learning D
5 likes 4 comments

Comments

sirpalee

Out of curiosity, do you know any commercial games or game studios who use D? Or non game related software?

I was checking their site / wikipedia but couldn't find a list of users.

March 08, 2016 12:42 AM
Aldacron

See the Current D Use page at the D Wiki. Just keep in mind that it's by no means comprehensive. Walter Bright (Digital Mars) provides support for some companies using D that haven't been public about it. Of interest to game developers is the DConf 2013 talk by Manu Evans (also linked from that page) on the experience Remedy Games had using D with their existing C++ game engine for one of their titles.

March 08, 2016 06:59 AM
GuyWithBeard

I can confirm that Quantum Break contains a fair amount of D code.

Check out Ethan Watson's DConf talk here: http://www.ustream.tv/recorded/86359657/highlight/699199

May 09, 2016 12:01 PM
Aldacron

I've just returned home after an extended trip following DConf and was going to post a link to Ethan's talk. Thanks for getting to it sooner :)

May 12, 2016 05:14 PM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Profile
Author
Advertisement
Advertisement