Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> You still get subclasses. And of course there's always the hack of declaring 
>> a subclass.
> 
>   A subclass can't access the private members of the base class.

Yeah, "protected" slipped my mind. It's still not hard to do if you're trying.

>> Or just using compiler-specific hackage to access the variables. 
> 
>   That has been made rather difficult in practice.

Err, has it? I can't say something like
   int * p = (int*) ((void*)(&yourInstance) + 32);
if I want access to whatever integer is 32 past the start of your class?

> If you are *intentionally*
> trying to break your program, then that's your choice, of course. However,
> in normal usage it's useful if the compiler checks that you don't make
> mistakes.

While I agree, I fail to see why using reflection as intended isn't "normal 
usage" and not "a mistake". It's not something you accidentally do. You know 
very well you're bypassing encapsulation. Not the least of which is that you 
need to give the name of the variable you want to access as a string.

>   Whether your program will link after that can depend on the compiler.
> It's certainly not standard-conforming. And again, you are hacking on
> purpose, trying to bypass the compiler checks, rather than using those
> checks to catch your mistakes.

Right. Since you said reflection violates encapsulation hard enough to make 
a program not "OO", I'm trying to figure out allowing type casts and 
assignment of arbitrary memory addresses to pointers doesn't.

Now, if the statement is "the compiler should be able to warn of external 
access to private variables, with the ability of the caller to easily 
indicate they know what they're doing," I'm 100% with you.

If the statement is "the compiler should error on external access to private 
variables, with no way to get around it," I'm 95% with you, with the caveat 
that "that's a pain in the ass way to write generic code that isn't type 
specific, because you have to write code generators instead of using the 
compiler you already have."

If the statement is "the compiler should error out on external access to 
private variables, but there should be a non-portable hacky and error-prone 
way to bypass it anyway, so you can't rely in your debugging efforts on what 
your code actually says," I'll just have to disagree with you there. :-)

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."

Post a reply to this message