Re: argument about encapsulating data sublanguage

"Marshall" <marshall.spight_at_gmail.com> wrote:

>While making pancakes this morning I thought of an argument about
>the idea we hear regularly from comp.object folks about how they want
>to hide SQL and the power of the dbms. This is a reductio ad absurdum
>argument; for this post, the irony dial is turned to 11:
>
>We often and rightly hear about the "impedance mismatch" between
>object-oriented code and other, lesser ways of doing things. The
>Object Masters are always exhorting us to encapsulate cohesive
>modules. But one area of opportunity is sadly neglected, and that
>is the encapsulation of the data sublanguage that is built right in
>to most OOPLs.
>
>Consider that most OOPLs, such as Java, contain a mix of notations.
>Both the modern OO notation "x.f(y)" and the old-fashioned math
>notation "x + y" are supported. But why should we continue to
>use such a low-level way of doing things?

     OTOH, x.f(y) is typical hierarchical chauvinism oppressing y merely because it is second. Have we not grown past that? Can we not have relationships between equals: x+y?

>Instead, let us encapsulate this separate math-y code into its
>own module. This lets us take some low-level math formula
>and replace it with a high-level abstract interface.
>
>After I've got some algorithms for my application code, I can
>either use low-level formulas:
>
> double dist = sqrt(dx*dx + dy*dy);
>
>Or I can create a higher-level interface that knows something about
>geometry:
>
> double dist = calcDistance(dx, dy);
>
>Using this technique I can hide my formulas behind a procedure.
>This enables me to use an intention-revealing descriptive name,
>rather than the relatively opaque "sqrt(x^2 + y^2)". Also, should
>my application requirements ever change such that I want to
>calculate distance a different way, I only have to change the
>implementation of calcDistance() in one place.

     And you might. Newtonian 3-D and distance on the globe are RW cases.

>Best of all, this lets me avoid sprinkling math formulas throughout
>my code. Yuck! That stuff needs to be segregated off in one
>place, so it doesn't gum up the works like so much sand.

     Have you figured out a way to avoid sprinkling logic throughout code? Many people do not seem to like logic much, and you would be doing them a favour.

[snip]

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:

     I have preferences.
     You have biases.
     He/She has prejudices.