Package permission and symbol resolution

Manu via Digitalmars-d digitalmars-d at puremagic.com
Tue Apr 22 04:00:41 PDT 2014


On 22 April 2014 19:16, John Colvin via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On Tuesday, 22 April 2014 at 08:07:32 UTC, Manu via Digitalmars-d wrote:
>>
>> So I've restructured one of my projects which is a C library bindings,
>> but also with some D-ification.
>>
>> I separated it into 2 parts, the raw binding parts, and the api
>> enhancements, the module structure looks like this:
>>
>> The Raw C binding part:
>>
>> pkg/c/module.d:
>>
>>   pkg.c.module;
>>
>>   struct ModuleStruct
>>   {
>>     package:
>>       int privateParts;
>>   }
>>
>>   extern (C) void func(const(char)* pString);
>>
>>
>> And the wrapping layer; public import's the raw C bindings, which is
>> meant to make the C API available too while adding some sugar for
>> convenience.
>>
>> pkg/module.d:
>>
>>   pkg.module;
>>
>>   public import pkg.c.module;
>>
>>   void func(const(char)[] str)
>>   {
>>     pkg.c.module.func(str.toStringz);
>>   }
>>
>>   void func2(ref ModuleStruct s)
>>   {
>>     s.privateParts += 10;
>>   }
>>
>>
>> I have a bunch of surprising problems.
>>
>> 1. Error: struct pkg.c.module.ModuleStruct member privateParts is not
>> accessible
>>
>> pkg.module can't access pkg.c.module.ModuleStruct.privateParts. Isn't
>> that what 'package' protection is for?
>
>
> package protection allows access from the current package and subpackages
> (pkg.c.* in this case), but not to anyone further up the tree
> (pkg.someModule).
>
> It would be nice one could write `protected(packageName)` to have better
> control over this.

Yeah, this seems like a problem, particularly since precisely what I'm
doing seems intuitive and desirable to me.
Are there other patterns to separate the sugar from the raw binding?
If the binding is generated, it can't coexist with the sugar or it'll
be overwritten each time.


> The rest of your problems are, I think, explained here:
> http://dlang.org/hijack.html

Ah ha!
"in order to overload functions from multiple modules together, an
alias statement is used to merge the overloads"

I've actually read this article before, but I forgot that detail.
Cheers mate! :)


More information about the Digitalmars-d mailing list