Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>>>> 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?
> 
>   You call that "easy"? To me it looks like garbage. You can't write code
> like that by mistake. You are deliberately writing non-standard code which
> triggers undefined behavior. You are not accessing a member variable, you
> are trashing memory.

Yes.  Of course, it could just look like
    alpha[i] = 32;
and you're equally screwed.  Or even
   &myInstance.update()
if my instance happened to be on the stack before but isn't now, and your 
instance is there instead.

Tell me why you think reflection can be done by mistake?

>   Well, if you want to intentionally break the modularity of your code with
> something like reflection, at the risk of breaking tons of code in the future,
> that's your choice.

Well, yes, that's kind of the point.

>   (If you use reflection to, for example, save the state of an object to
> a database to be retrieved later, haven't you kind of locked up the
> structure of that object? You can't make *any* changes whatsoever to it
> without breaking all the stored objects in the database. Doesn't sound
> very enhanceable to me.)

Without reflection, you have no generalized way to handle this. With 
reflection, you can write code that does the right thing. Of course this is 
simplified.

But the same is true of a manually-implemented class.

And when you're serializing something to (for example) store as a hidden 
field on a web page, chances are when you update the code whoever is in the 
middle of a session is going to break anyway.

Or, when you change the shape, you fix the database appropriately.

>   If you trash memory, you are writing non-portable, non-standard-conforming
> code. All bets are off.

You're making a mistake that is arguably easier to make than using a name 
that starts with an underline.

That's exactly what I'm saying: If you make a mistake, all bets are off. So 
you're counting on the perfection of every author and contributor to your 
codebase to always do the write thing, because the compiler *doesn't* check 
that it's right, and the runtime *doesn't* check that it's right.

So I'm not seeing why the compiler not checking for you intentionally using 
a private variable is *less* encapsulated than the compiler not checking you 
don't accidentally have a wild pointer. The "standards-compliant" Python 
code says "don't dick with the private variables of an instance unless you 
want code that's fragile when that class gets upgraded."

In my experience, I'd much rather use a language where the access rules are 
enforced, even if those access rules allow well-defined methods of getting 
at private variables, than to use a language where a mistake by one 
programmer breaks code in a completely unrelated programmer's module. That's 
just my experience, tho.

>> 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. :-)
> 
>   Where have I said "there should be a non-portable way to bypass it"?
> 
>   There may be a non-portable way of bypassing it. That's different from
> "there should be".

So you're saying having non-portable ways of bypassing the typing is better 
than having portable ways of bypassing the typing?  C# is less encapsulated 
than C++, because C# has documented ways of intentionally getting to private 
variables, but C++ has only accidental compiler-specific ways of getting at 
private variables?

How about a declaration on a class that says "It's OK for someone to bypass 
the private declarations and use reflection on this class", while classes 
without that declaration would not be accessible from the reflection 
methods. What do you think of that idea?

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