> Date: Mon, 31 Aug 1998 15:04:21 -0400
> From: "Peter Shenkin" <[log in to unmask]>
> Of course, since "=" can now be carried out by a user-defined
> SUBROUTINE, even that indication can be misleading. Still,
> despite Jim's points, I like the idea of READONLY PRIVATE
> variables. His points regarding inlining are good ones, but I
> don't think READONLY breaks encapsulation; it just provides a
> different mechanism -- one just as safe as a "get" function
> -- to query PRIVATE data.
> -P.
I disagree strongly. External access to the internal variable names of an
encapsulated module or structure _is_not_ as safe as a "get" function. If you
change the encapsulated implementation, then the application code may break
(i.e. not work correctly). If you recompile the application code, the compiler
may tell you of this, or it may not. Hardly what I would call safe. The get
function may be less efficient (but it doesn't have to be), but efficiency
isn't the issue here, safety is.
This is the whole point of encapsulation. Safety comes with a price.
Maybe an efficiency loss. Maybe a few more characters to type in the
application code. "There ain't no such thing as a free lunch".
If the performance of your application depends on the speed of
access to PRIVATE (encapsulated) data, the odds are high that the architecture
of the module or the application (or both) is wrong.
-david
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|