|
 |
Warp wrote:
> Darren New <dne### [at] san rrcom> wrote:
>> I disagree. Now you've got a naming convention that isn't enforced that
>> would mean something to people trying to read your code.
>
> You mean the naming convention *is* enforced by languages which do not
> explicitly support private data?
Not exactly.
In Python (and, AFAIK, LISP), getting to private functions, for example,
requires you to explicitly name the module and private function, and say
"pull them into my space."
However, you can get to private members without doing that.
Therefore, the convention is that private members are given names that
indicate they're intended to be private. Private functions don't need that
naming convention, because there's a list out there in the source code that
distinguishes private from public. That list is only enforced by default,
but you can work around it if you care to read the code and see what isn't
exported, or if you grope into the generated code and look what's there.
Even if it were enforced in Python, the metadata is there to be used and
abused. You can go into the data structures that make up the class or the
instance and modify them, because that's exactly how the system works
normally. The compiler works by building those data structures at runtime,
so if the compiler can do it, so can you. That's why the original article
talked about dynamic systems, i.e., systems that you can change at runtime.
For example (and very simplified), in Python, each object has a hashtable
mapping the names of fields to their values. Each member object of each
class and instance is in a hashtable. The hashtable is called "__dict__", so
xyz.__dict__["hello"] is the same as xyz.hello. If you marked "hello" as
private (even if you could), code could still get to it via __dict__. If you
marked __dict__ as private, all kinds of meta stuff would break.
--
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
|
|
