• dsimcha <dsimcha yahoo.com> May 11 2009
• Ellery Newcomer <ellery-newcomer utulsa.edu> May 11 2009
• Christopher Wright <dhasenan gmail.com> May 12 2009
• dsimcha <dsimcha yahoo.com> May 12 2009
• Christopher Wright <dhasenan gmail.com> May 12 2009
• Michel Fortin <michel.fortin michelf.com> May 13 2009

dsimcha <dsimcha yahoo.com> writes:

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.

Ellery Newcomer <ellery-newcomer utulsa.edu> writes:

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.

Christopher Wright <dhasenan gmail.com> writes:

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.

dsimcha <dsimcha yahoo.com> writes:

== 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.


 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.

Christopher Wright <dhasenan gmail.com> writes:

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.


 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.

Michel Fortin <michel.fortin michelf.com> writes:

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/