nemesis wrote:
> Darren New escreveu:
>> Warp wrote:
>>> nemesis <nam### [at] gmailcom> wrote:
>>>>>   Ok, "written agreement" then, if you want to nitpick. Not much 
>>>>> difference.
>>>>> Still not enforced nor sanity-checked by anyone or anything.
>>>
>>>> Here is where Larry Wall's quote really applies. ;)
>>>
>>>   Since when have code sanity checks become a bad thing?
>>
>> When they become something to work around, rather than a help to the 
>> programmer. If you need to go read the source code of the module 
>> you're accessing to figure out how to get to the private variables, 
>> it's no longer a "code sanity check" IMO.
> 
> Err... I think here I'll have to agree with Warp.  Why would you try to 
> bypass the "code sanity checks" and all the paranoid safety devices to 
> access something you shouldn't be accessing in the first place?



Because, every once in a while, the provider of the library wasn't omniscient.

It's pretty simple. It's a practical thing. Say you have (just for an 
example) a video codec. It does all kinds of nice things with timestamps and 
such, but one thing it doesn't provide is telling you the current frame 
number. However, that is stored in a private variable (which you can see 
from reading the .h file), and for some reason you need that information to 
implement your player in an environment the original author didn't intend 
his player to be used in.

You have three choices:
1) Violate encapsulation, and pay the price if you ever need to use a new 
version of the decoder that doesn't have the frame number in the same place.

2) Rewrite the entire video decoder from scratch.

3) Find the owner of the original code and get him to change it and agree to 
support it indefinitely.

It's a cost vs benefit thing.


You "shouldn't" be accessing the internal data structures NTFS stores on the 
disk. It makes it kind of hard to make an open source NTFS driver without 
doing so. If your systems *really* prevented that access, such drivers would 
be impossible to write. When MS changes the NTFS drivers, Linux maintainers 
have to go in, reverse engineer things again, and fix stuff up to stay 
compatible. That's a cost that wouldn't be borne if Microsoft's NTFS was 
open source and there was only one code base.

Sure, if you have the source code to the module, providing public access to 
the private variable is pretty easy. I'd not recommend bypassing the 
protection mechanisms in that case. I thought that would be obvious to 
people, tho, so I assumed everyone was on the same page with me there. 
(Which is not to say anyone disagrees or has disagreed with that here.)



> This thread has long derailed into something quasi-metaphysical... :P

I'm thinking it's something very practical. I'm not advocating regularly 
accessing the internals of other objects. I'm just saying that preventing it 
by convention or by hiding information from the humans isn't any worse IMO 
than implementing it in the compiler.

> My final word here is:  to have modularity you don't need all the traps, 
> contraption devices and alarmist chainballs with all the barroque syntax 
> associated.  All you need is to agree to use only what a module provides 
> you.  

And to be able to tell easily when you're violating it. If you have to read 
prose documentation to know whether some routine or variable is private or 
public, *then* you lack modularity.

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