Is there any hack in D that will allow overriding of privacy settings on classes?  For example, I really need a feature that will force D to let me mess with the internals of a class that I have no control over from a subclass, effectively making private members protected.

I know this is a bad idea, yada yada yada, but I feel like a language that allows manual memory management, casting away immutable, and inline assembler should allow some backdoor to cast away private.  Is this anywhere?  If not, we should really consider including a cast(public) or something in the spirit that, ultimately, the programmer knows what he/she is doing and the language should treat the programmer like a consenting adult.

dsimcha wrote:
> Is there any hack in D that will allow overriding of privacy settings on
> classes?  For example, I really need a feature that will force D to let me
> mess with the internals of a class that I have no control over from a
> subclass, effectively making private members protected.
> 
> I know this is a bad idea, yada yada yada, but I feel like a language that
> allows manual memory management, casting away immutable, and inline assembler
> should allow some backdoor to cast away private.  Is this anywhere?  If not,
> we should really consider including a cast(public) or something in the spirit
> that, ultimately, the programmer knows what he/she is doing and the language
> should treat the programmer like a consenting adult.

You frighten my hoagie.

dsimcha wrote:
> Is there any hack in D that will allow overriding of privacy settings on
> classes?  For example, I really need a feature that will force D to let me
> mess with the internals of a class that I have no control over from a
> subclass, effectively making private members protected.
> 
> I know this is a bad idea, yada yada yada, but I feel like a language that
> allows manual memory management, casting away immutable, and inline assembler
> should allow some backdoor to cast away private.  Is this anywhere?  If not,
> we should really consider including a cast(public) or something in the spirit
> that, ultimately, the programmer knows what he/she is doing and the language
> should treat the programmer like a consenting adult.

There is one way to do it, but it's ugly:

mixin(Replace!(import("path/to/dfile.d"), "private", "public"));

This requires a compile-time Replace template, which I don't have.

== Quote from Christopher Wright (dhasenan@gmail.com)'s article
> dsimcha wrote:
> > Is there any hack in D that will allow overriding of privacy settings on classes?  For example, I really need a feature that will force D to let me mess with the internals of a class that I have no control over from a subclass, effectively making private members protected.
> >
> > I know this is a bad idea, yada yada yada, but I feel like a language that allows manual memory management, casting away immutable, and inline assembler should allow some backdoor to cast away private.  Is this anywhere?  If not, we should really consider including a cast(public) or something in the spirit that, ultimately, the programmer knows what he/she is doing and the language should treat the programmer like a consenting adult.
> There is one way to do it, but it's ugly:
> mixin(Replace!(import("path/to/dfile.d"), "private", "public"));
> This requires a compile-time Replace template, which I don't have.

Awesome, but wait a minute, if you can just mixin the contents of another module like that, then we don't have a problem.  You can access private members in the same module.  Just mix in that module instead of importing it and...you're done.

dsimcha wrote:
> == Quote from Christopher Wright (dhasenan@gmail.com)'s article
>> dsimcha wrote:
>>> Is there any hack in D that will allow overriding of privacy settings on
>>> classes?  For example, I really need a feature that will force D to let me
>>> mess with the internals of a class that I have no control over from a
>>> subclass, effectively making private members protected.
>>>
>>> I know this is a bad idea, yada yada yada, but I feel like a language that
>>> allows manual memory management, casting away immutable, and inline assembler
>>> should allow some backdoor to cast away private.  Is this anywhere?  If not,
>>> we should really consider including a cast(public) or something in the spirit
>>> that, ultimately, the programmer knows what he/she is doing and the language
>>> should treat the programmer like a consenting adult.
>> There is one way to do it, but it's ugly:
>> mixin(Replace!(import("path/to/dfile.d"), "private", "public"));
>> This requires a compile-time Replace template, which I don't have.
> 
> Awesome, but wait a minute, if you can just mixin the contents of another module
> like that, then we don't have a problem.  You can access private members in the
> same module.  Just mix in that module instead of importing it and...you're done.

True. Though you need to be careful about including the 'module' statement.

On 2009-05-12 07:14:43 -0400, Christopher Wright <dhasenan@gmail.com> said:

> dsimcha wrote:
>> Is there any hack in D that will allow overriding of privacy settings on
>> classes?  For example, I really need a feature that will force D to let me
>> mess with the internals of a class that I have no control over from a
>> subclass, effectively making private members protected.
>> 
>> I know this is a bad idea, yada yada yada, but I feel like a language that
>> allows manual memory management, casting away immutable, and inline assembler
>> should allow some backdoor to cast away private.  Is this anywhere?  If not,
>> we should really consider including a cast(public) or something in the spirit
>> that, ultimately, the programmer knows what he/she is doing and the language
>> should treat the programmer like a consenting adult.
> 
> There is one way to do it, but it's ugly:
> 
> mixin(Replace!(import("path/to/dfile.d"), "private", "public"));
> 
> This requires a compile-time Replace template, which I don't have.

Basically, this is no different than copy-pasting the original in your own module and doing the replace yourself. To the compiler's eye, those "imported" symbols and types will have different names, and thus will be different and incompatible symbols and types.


-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/