DIP16: Transparently substitute module with package

Derek ddparnell at bigpond.com
Sat Mar 31 02:07:28 PDT 2012


On Sat, 31 Mar 2012 01:46:19 +1100, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> Starting a new thread from one in announce:
>
> http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP16
>
> Please comment ...

We solved this issue in the Euphoria Programming language by introducing  
the concept of 'public include'.

The 'include' directive is similar to DPL's 'import' directive. Normally  
when a file (module) is included, its public identifiers are *only*  
visible to the including module and not further module up the include  
tree. However, if a module is 'public include'd then its public  
identifiers are set up *as if* they were actually declared in the  
including module rather than the included module.

Thus if Euphoria's module called datetime.e gets too large, we split it  
into, say two or three new modules and replace the code in datetime.e with  
corresponding 'public include' statements, thus making it a type of  
package definition. This means that existing application code does not  
have to be modified and future code can choose to include either the  
entire package called datetime.e or individual modules that go into making  
that package.

 From the POV of a developer, creating a package out of what was a module  
is transparent. They do not even know or have to care in order to use it.  
There are no complicated access rules that can one day trip people up.

We made one tweak to the public identifier declaration though to cater for  
situations in which an identifier which was currently local to a module,  
but when moved to a new module when the original was transformed to a  
package, still had to be visible to the code in the package file but  
invisible to code including the package. We created the 'export' qualifier  
on an identifier declaration to signal such an item.

Original module code ...

   function to_seconds(datetime x)  /* A local function to the module */

   public function local_to_gmt(datetime x) /* A publicly exposed function  
*/

New module code ...

   export function to_seconds(datetime x)  /* A function visible to the  
package file only */

   public function local_to_gmt(datetime x) /* A publicly exposed function  
*/


This means that application that include the package datetime.e will not  
see to_seconds() but code in the datetime.e will see it, and  
local_to_gmt() will be seen by the application code and the package code.


-- 
Derek Parnell
Melbourne, Australia


More information about the Digitalmars-d mailing list