www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - cast(public)

reply dsimcha <dsimcha yahoo.com> writes:
I know I've probably mentioned this one here before, but it was buried in long
threads.

Could we put a feature in the language that allows private member variables to
be cast to public?  The idea is that, if a class/struct designer makes
something private, they're saying it's a bad idea to mess with it, and that
you do so at your own risk.  However, I think there needs to be a back door to
cowboy this one, because otherwise private/protected is just too restrictive
for a language like D.  It would work something like this:

struct Foo {
    private uint bar;
}

void main() {
    Foo foo;
    foo.bar++;  // error
    (cast(public) foo.bar)++;  // Works.
}
Jul 17 2009
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
dsimcha:

 I think there needs to be a back door to
 cowboy this one, because otherwise private/protected is just too restrictive
 for a language like D.


Just like in Python! ^_^

Bye,
bearophile
Jul 17 2009
prev sibling next sibling parent Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
dsimcha wrote:


 Could we put a feature in the language that allows private member
 variables to
 be cast to public?  The idea is that, if a class/struct designer makes
 something private, they're saying it's a bad idea to mess with it, and
 that
 you do so at your own risk.  However, I think there needs to be a back
 door to cowboy this one


In general don't believe this is a good idea. Calling private functions and
accessing private variables may violate the class invariant. That's why it
should only be done by member functions, which are bound to maintain that
invariant.

If there was such a back door, a class invariant would mean nothing. Neither
the compiler nor the programmer could ever depend upon it.

However, since D is a systems programming language, which can already cast
away constness and such, it might fit.

-- 
Michiel Helvensteijn
Jul 17 2009
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"dsimcha" <dsimcha yahoo.com> wrote in message 
news:h3q5td$2jqa$1 digitalmars.com...

I know I've probably mentioned this one here before, but it was buried in 
long
 threads.

 Could we put a feature in the language that allows private member 
 variables to
 be cast to public?  The idea is that, if a class/struct designer makes
 something private, they're saying it's a bad idea to mess with it, and 
 that
 you do so at your own risk.  However, I think there needs to be a back 
 door to
 cowboy this one, because otherwise private/protected is just too 
 restrictive
 for a language like D.  It would work something like this:

 struct Foo {
    private uint bar;
 }

 void main() {
    Foo foo;
    foo.bar++;  // error
    (cast(public) foo.bar)++;  // Works.
 }


I don't see a real legitimate point to this. If you need something from a 
module not provided by a public interface (or protected sub-classing) than 
that needs to be properly added to the module's interface. Otherwise you're 
just asking for your code to be broken (in a way that may *or* may not be 
fixable) the moment the module you're hacking into is updated. Why hack it, 
when you could just make a proper added feature? Sure, there may be 
source-not-available stuff, but if you need some extra feature from a 
library that doesn't have source available, and the lib's developers aren't 
receptive to your need, then you're just simply using the wrong library 
anyway.
Jul 17 2009
next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Fri, Jul 17, 2009 at 12:20 PM, Nick Sabalausky<a a.a> wrote:

 "dsimcha" <dsimcha yahoo.com> wrote in message
 news:h3q5td$2jqa$1 digitalmars.com...

I know I've probably mentioned this one here before, but it was buried in
long
 threads.

 Could we put a feature in the language that allows private member
 variables to
 be cast to public? =A0The idea is that, if a class/struct designer makes
 something private, they're saying it's a bad idea to mess with it, and
 that
 you do so at your own risk. =A0However, I think there needs to be a back
 door to
 cowboy this one, because otherwise private/protected is just too
 restrictive
 for a language like D. =A0It would work something like this:

 struct Foo {
 =A0 =A0private uint bar;
 }

 void main() {
 =A0 =A0Foo foo;
 =A0 =A0foo.bar++; =A0// error
 =A0 =A0(cast(public) foo.bar)++; =A0// Works.
 }


 I don't see a real legitimate point to this. If you need something from a
 module not provided by a public interface (or protected sub-classing) tha=


n

 that needs to be properly added to the module's interface. Otherwise you'=


re

 just asking for your code to be broken (in a way that may *or* may not be
 fixable) the moment the module you're hacking into is updated. Why hack i=


t,

 when you could just make a proper added feature? Sure, there may be
 source-not-available stuff, but if you need some extra feature from a
 library that doesn't have source available, and the lib's developers aren=


't

 receptive to your need, then you're just simply using the wrong library
 anyway.


If you can get the offset of a private member you can always do some
pointer arithmetic to get the offset to the member you want to change.

   cast(Thing)(cast(void*)(object) + offsetofPrivateMember);

Or something like that which looks appropriately evil given that
you're doing something you're not supposed to.

I would much rather see variants of cast that guarantee they won't
reinterpret.  cast(int)IThoughItWasANumberButItsAnObject.  Eek.

--bb
Jul 17 2009
prev sibling next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Nick Sabalausky (a a.a)'s article

 "dsimcha" <dsimcha yahoo.com> wrote in message
 news:h3q5td$2jqa$1 digitalmars.com...

I know I've probably mentioned this one here before, but it was buried in
long
 threads.

 Could we put a feature in the language that allows private member
 variables to
 be cast to public?  The idea is that, if a class/struct designer makes
 something private, they're saying it's a bad idea to mess with it, and
 that
 you do so at your own risk.  However, I think there needs to be a back
 door to
 cowboy this one, because otherwise private/protected is just too
 restrictive
 for a language like D.  It would work something like this:

 struct Foo {
    private uint bar;
 }

 void main() {
    Foo foo;
    foo.bar++;  // error
    (cast(public) foo.bar)++;  // Works.
 }


 I don't see a real legitimate point to this. If you need something from a
 module not provided by a public interface (or protected sub-classing) than
 that needs to be properly added to the module's interface. Otherwise you're
 just asking for your code to be broken (in a way that may *or* may not be
 fixable) the moment the module you're hacking into is updated. Why hack it,
 when you could just make a proper added feature? Sure, there may be
 source-not-available stuff, but if you need some extra feature from a
 library that doesn't have source available, and the lib's developers aren't
 receptive to your need, then you're just simply using the wrong library
 anyway.


What if you want to make the class/struct do something that is enough of a
corner
case that making a formal interface to do what you want would bloat the API for
the other 99.9% of use cases?  IMHO at a more general level sometimes the best
thing to do when trying to solve corner cases is to just hack it, so that you
can
simplify the more normal cases.
Jul 17 2009
parent "Nick Sabalausky" <a a.a> writes:
"dsimcha" <dsimcha yahoo.com> wrote in message 
news:h3qkvv$n5q$1 digitalmars.com...

 What if you want to make the class/struct do something that is enough of a 
 corner
 case that making a formal interface to do what you want would bloat the 
 API for
 the other 99.9% of use cases?  IMHO at a more general level sometimes the 
 best
 thing to do when trying to solve corner cases is to just hack it, so that 
 you can
 simplify the more normal cases.


I can't imagine a scenario where that would actually be a legitimate 
concern. All you'd really need to do is point out in the documentation for 
it that it's not typically needed. Worst case scenario, have the 
documentation grouped by "normal" and "advanced". Or hell, even just leave 
it undocumented. It's not as if formalizing a rarely-needed feature would 
suddenly mean that everyone else has to start using it.
Jul 17 2009
prev sibling next sibling parent BCS <ao pathlink.com> writes:
Reply to Nick,


 Sure, there may be source-not-available stuff,


If the lib is source-not-available, how will you even know what non public 
stuff there is to access?
Jul 17 2009
prev sibling parent Onassis Empederado <OEmpederado gmail.com> writes:
Nick Sabalausky Wrote:


 "dsimcha" <dsimcha yahoo.com> wrote in message 
 news:h3q5td$2jqa$1 digitalmars.com...

I know I've probably mentioned this one here before, but it was buried in 
long
 threads.

 Could we put a feature in the language that allows private member 
 variables to
 be cast to public?  The idea is that, if a class/struct designer makes
 something private, they're saying it's a bad idea to mess with it, and 
 that
 you do so at your own risk.  However, I think there needs to be a back 
 door to
 cowboy this one, because otherwise private/protected is just too 
 restrictive
 for a language like D.  It would work something like this:

 struct Foo {
    private uint bar;
 }

 void main() {
    Foo foo;
    foo.bar++;  // error
    (cast(public) foo.bar)++;  // Works.
 }


 
 I don't see a real legitimate point to this. If you need something from a 
 module not provided by a public interface (or protected sub-classing) than 
 that needs to be properly added to the module's interface. Otherwise you're 
 just asking for your code to be broken (in a way that may *or* may not be 
 fixable) the moment the module you're hacking into is updated. Why hack it, 
 when you could just make a proper added feature? Sure, there may be 
 source-not-available stuff, but if you need some extra feature from a 
 library that doesn't have source available, and the lib's developers aren't 
 receptive to your need, then you're just simply using the wrong library 
 anyway.
 
 


It depends on the type of interface classes (implementation versus user-level
interface using concrete/abstract types), where derived class can be created
from it, considering with some levels of abstraction...by design.

Just my 2 cents.
Jul 17 2009
prev sibling next sibling parent reply downs <default_357-line yahoo.de> writes:
dsimcha wrote:

 I know I've probably mentioned this one here before, but it was buried in long
 threads.
 
 Could we put a feature in the language that allows private member variables to
 be cast to public?  The idea is that, if a class/struct designer makes
 something private, they're saying it's a bad idea to mess with it, and that
 you do so at your own risk.  However, I think there needs to be a back door to
 cowboy this one, because otherwise private/protected is just too restrictive
 for a language like D.  It would work something like this:
 
 struct Foo {
     private uint bar;
 }
 
 void main() {
     Foo foo;
     foo.bar++;  // error
     (cast(public) foo.bar)++;  // Works.
 }


I can second this.

For instance, in Phobos1 there is no way to create a Socket from a file handle,
so I have to monkey with offsets in my IRC bot code.
Jul 17 2009
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
downs escribió:

 dsimcha wrote:

 I know I've probably mentioned this one here before, but it was buried in long
 threads.

 Could we put a feature in the language that allows private member variables to
 be cast to public?  The idea is that, if a class/struct designer makes
 something private, they're saying it's a bad idea to mess with it, and that
 you do so at your own risk.  However, I think there needs to be a back door to
 cowboy this one, because otherwise private/protected is just too restrictive
 for a language like D.  It would work something like this:

 struct Foo {
     private uint bar;
 }

 void main() {
     Foo foo;
     foo.bar++;  // error
     (cast(public) foo.bar)++;  // Works.
 }


 
 I can second this.
 
 For instance, in Phobos1 there is no way to create a Socket from a file
handle, so I have to monkey with offsets in my IRC bot code.


Did you ask for an enhancement?
Jul 17 2009
parent reply downs <default_357-line yahoo.de> writes:
Ary Borenszweig wrote:

 downs escribió:

 dsimcha wrote:

 I know I've probably mentioned this one here before, but it was
 buried in long
 threads.

 Could we put a feature in the language that allows private member
 variables to
 be cast to public?  The idea is that, if a class/struct designer makes
 something private, they're saying it's a bad idea to mess with it,
 and that
 you do so at your own risk.  However, I think there needs to be a
 back door to
 cowboy this one, because otherwise private/protected is just too
 restrictive
 for a language like D.  It would work something like this:

 struct Foo {
     private uint bar;
 }

 void main() {
     Foo foo;
     foo.bar++;  // error
     (cast(public) foo.bar)++;  // Works.
 }


 I can second this.

 For instance, in Phobos1 there is no way to create a Socket from a
 file handle, so I have to monkey with offsets in my IRC bot code.


 
 Did you ask for an enhancement?


Phobos*1*.
Jul 18 2009
parent Ary Borenszweig <ary esperanto.org.ar> writes:
downs escribió:

 Ary Borenszweig wrote:

 downs escribió:

 dsimcha wrote:

 I know I've probably mentioned this one here before, but it was
 buried in long
 threads.

 Could we put a feature in the language that allows private member
 variables to
 be cast to public?  The idea is that, if a class/struct designer makes
 something private, they're saying it's a bad idea to mess with it,
 and that
 you do so at your own risk.  However, I think there needs to be a
 back door to
 cowboy this one, because otherwise private/protected is just too
 restrictive
 for a language like D.  It would work something like this:

 struct Foo {
     private uint bar;
 }

 void main() {
     Foo foo;
     foo.bar++;  // error
     (cast(public) foo.bar)++;  // Works.
 }


 I can second this.

 For instance, in Phobos1 there is no way to create a Socket from a
 file handle, so I have to monkey with offsets in my IRC bot code.


 Did you ask for an enhancement?


 
 Phobos*1*.


Well, anyway, casting things to public is not the solution. Phobos1 
should still be maintained. It's silly that just a couple of people are 
working on the standard library...
Jul 18 2009
prev sibling next sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
dsimcha wrote:

 struct Foo {
     private uint bar;
 }
 
 void main() {
     Foo foo;
     foo.bar++;  // error
     (cast(public) foo.bar)++;  // Works.
 }


----
struct Foo {
    private uint bar;
}

void main() {
    Foo foo;
    foo.bar++;  // This works for me with dmd 1.026,
                // dmd 2.031 and ldc r1411
    // foo.bar is now 1.
}
----

Same effect for classes... Am I missing something or is this a bug?
Jul 18 2009
next sibling parent reply Robin KAY <komadori gekkou.co.uk> writes:
Robert Clipsham wrote:

 struct Foo {
    private uint bar;
 }
 
 void main() {
    Foo foo;
    foo.bar++;  // This works for me with dmd 1.026,
                // dmd 2.031 and ldc r1411
    // foo.bar is now 1.
 }
 ----
 
 Same effect for classes... Am I missing something or is this a bug?


None of the protection attributes have any effect within a module. 
Members of the same module are always "friends".

See: http://www.digitalmars.com/d/2.0/attribute.html#ProtectionAttribute

-- 
Robin KAY
Jul 18 2009
parent Robert Clipsham <robert octarineparrot.com> writes:
Robin KAY wrote:

 Robert Clipsham wrote:

 struct Foo {
    private uint bar;
 }

 void main() {
    Foo foo;
    foo.bar++;  // This works for me with dmd 1.026,
                // dmd 2.031 and ldc r1411
    // foo.bar is now 1.
 }
 ----

 Same effect for classes... Am I missing something or is this a bug?


 
 None of the protection attributes have any effect within a module. 
 Members of the same module are always "friends".
 
 See: http://www.digitalmars.com/d/2.0/attribute.html#ProtectionAttribute
 


Oh, cool, didn't know that. Thanks!
Jul 18 2009
prev sibling parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= writes:
Robert Clipsham schrieb:

 dsimcha wrote:

 struct Foo {
     private uint bar;
 }

 void main() {
     Foo foo;
     foo.bar++;  // error
     (cast(public) foo.bar)++;  // Works.
 }


 
 ----
 struct Foo {
    private uint bar;
 }
 
 void main() {
    Foo foo;
    foo.bar++;  // This works for me with dmd 1.026,
                // dmd 2.031 and ldc r1411
    // foo.bar is now 1.
 }
 ----
 
 Same effect for classes... Am I missing something or is this a bug?


Protection attributes will be ignored inside of the same module. This is 
by design to have an alternative for C++ friend declarations.
Jul 18 2009
prev sibling parent Robert Clipsham <robert octarineparrot.com> writes:
dsimcha wrote:

 I know I've probably mentioned this one here before, but it was buried in long
 threads.
 
 Could we put a feature in the language that allows private member variables to
 be cast to public?  The idea is that, if a class/struct designer makes
 something private, they're saying it's a bad idea to mess with it, and that
 you do so at your own risk.  However, I think there needs to be a back door to
 cowboy this one, because otherwise private/protected is just too restrictive
 for a language like D.  It would work something like this:
 
 struct Foo {
     private uint bar;
 }
 
 void main() {
     Foo foo;
     foo.bar++;  // error
     (cast(public) foo.bar)++;  // Works.
 }


----
// There's a phobos function for this somewhere too,
// I couldn't be bothered looking for it though
import tango.core.Array : rfind;

T* get(T, char[] member, S)( ref S s )
{
   foreach( k, v; s.tupleof )
   {
      auto rdot = rfind( s.tupleof[k].stringof, "." ) + 1;
      if( s.tupleof[k].stringof[rdot .. $] == member )
      {
           static if( is( S == struct ) )
              return cast(T*)(cast(void*)&s + s.tupleof[k].offsetof);
           else
              return cast(T*)(cast(void*)s + s.tupleof[k].offsetof);
      }
   }
   return null;
}

void main()
{
   Foo foo;
   uint* bar = get!(uint, "bar")(foo);
   (*bar)++;
}
----

Who needs cast(public) anyways? :P
Jul 18 2009