Re: argument about encapsulating data sublanguage
Date: Fri, 29 Dec 2006 18:51:34 GMT
Message-ID: <Wsdlh.38446$cz.565970_at_ursa-nb00s0.nbnet.nb.ca>
Walt wrote:
> "Marshall" <marshall.spight_at_gmail.com> wrote in message > news:1167333635.567797.260230_at_a3g2000cwd.googlegroups.com... >
>>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?
>>
>>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.
> > When you hide your formulas behind a procedure, what does the procedure > stand for? Does it stand for the hidden formulas, or for the results the > hidden formulas yield?
Thinking about Marshall's parody, it occurs to me subprograms are like lemmas.
Lemmas are only useful if one can see the proof itself to verify it for oneself. Once one trusts the lemma, one can use it as a building block for larger proofs.
It then occurs to me that views are the ultimate subprograms.
Procedures kinda do something similar but not nearly so well.
>>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.
> > Some programmers would say the same thing about "all the I/O code", or "all > the DBMS specific code" or "all the OS specific code".
Indeed.
>>Marshall
>>
>>PS. Reducto Ad Absurdum was named for Dr. Myron Reducto.
>>
>> http://en.wikipedia.org/wiki/Harvey_birdman#Rival_lawyers
Did you click through the link to the description of reducto ad absurdum proofs? Received on Fri Dec 29 2006 - 19:51:34 CET