Bill Moran <wmoran@potentialtech.com> writes:
> Greg Stark wrote:
> >
> > Note that this is largely a C++ rule. In C++ accessing class members is very
> > different and much less flexible than using class methods. Other OO languages
> > are not universally so hobbled.
>
> Really? I can only assume you're referring to languages such as perl that have
> ties (or equivalent capability). In that case, you're still accessing the data
> through a method, it's just a more abstract abstraction. Or are you referring
> to something else?
Well the original motivation is that in C++ member references are handled as C
structure member references which hard code the offset in the structure into
the code. This means nearly any change to your class such as changing member
ordering, changing data types, or adding a member anywhere but at the end
introduces ABI changes that no linker can detect.
Method references on the other hand are resolved by name by the linker. The
linker can resolve problems and you can provide legacy fall-back methods for
old code. So in C++ maintaining a stable ABI is much easier using method calls
than member references.
Languages such as Perl, or Lisp, or most any other OO languages not trying to
maintain C style efficiency resolve member references by name so you can add
or change the "order" of your members without introducing "abi"
incompatibility.
> The last thing we'd want is someone getting the wrong answer to a financial
> query because they don't understand the schema. A much more reliable way is
> to have them
>
> SELECT * FROM get_monthy_payment(month, account); so we know they're getting
> the correct answer.
Of course that doesn't really change the need for the person writing the query
to understand the schema, it just changes which tools that person's working
with. Whoever wrote get_monthy_payment could just as easily get the query
wrong, especially since they seem to be a poor typist :)
You can do the same thing without depending on stored procedures by enforcing
that only low level modules of your application under the control of the same
schema-aware people get to write SQL queries. Upper level modules are only
allowed to call $account->get_monthly_payment($month).
This has the advantage that if get_monthly_payment involves doing several
queries and incorporating out-of-database information it can do so without
forcing people to use awkward database procedural languages or imposing awkard
apis.
--
greg
