www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Overriding Private

reply 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.
May 11 2009
next sibling parent 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.
May 11 2009
prev sibling parent reply 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.
May 12 2009
next sibling parent reply 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.


 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.
May 12 2009
parent 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.


 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.
May 12 2009
prev sibling parent 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/
May 13 2009