|
 |
Warp wrote:
> I really fail to see how that is different from using a *real* interface
> specification, rather than just a verbal one.
It's not "verbal". It's expressed in the code. It just so happens that
there's a way to bypass it. You say "My module exports the functions alpha,
beta, and gamma." You then later define alpha, beta, gamma, and delta. The
caller can't get to delta without explicitly saying "hey, you know that
private function delta in that module? Import it into my module."
It's not something you do by mistake.
> http://warp.povusers.org/FunctionParser/
>
> And by "totally" I mean literally write everything from scratch. And
> no external code breaks. That's the nice thing about modularity. It allows
> me to do that safely.
And then someone comes and says "Gee, parsing this function each time is
adding too much overhead. We need to store that structure in a database. And
then we need to calculate it at the server and then ship the bytecodes to
each client." And you're either screwed, or you bypass the private part to
make it work knowing you'll break on the next release of the library. Or you
pick the source up, and maintain it yourself in the future, which is just a
special case of #2 there.
> Brevity is *not* always the answer.
You should try Ada! ;-)
In any case, that sort of import is exactly the sort of way you bypass the
access restrictions on exported functions in Python, for example. You have
to go read the source (to find the name), then explicitly copy the function
into your own namespace to invoke it.
> I disagree. There's no modularity if you can't enforce access rights.
And you can't enforce access rights in C++, because nothing prevents wild
pointers from clobbering anything in memory.
WarpsClass x(...);
memset(&x,0,23);
If you think that's somehow unfair, then how is reflection any less fair?
--
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
|
|
