Re: Object-relational impedence
Date: Wed, 5 Mar 2008 21:10:11 +0100
Message-ID: <1i7hprcoy3j63.2c2zgpld4s2b$.dlg_at_40tude.net>
On Wed, 05 Mar 2008 09:57:23 -0500, Thomas Gagne wrote:
> Dmitry A. Kazakov wrote:
>> On Wed, 5 Mar 2008 01:10:01 -0600, Robert Martin wrote:
>>
>>> <snip>
>>> You are confusing OO with static typing. In OO languages like Ruby,
>>> Python, or Smalltalk you can pass any object to any function
>>> irrespective of type.
>>
>> Which is a bad idea.
>>
> Why?
Because it is in fact untyped.
>> Nevertheless you don't need dynamic typing in order to deal with that. You
>> could have a class of relations in order to define operations (like join)
>> on them. That will give a static type to the result of any join.
> At what cost given a similar benefit can be gained without the extra effort?
No extra efforts. If I wanted to mix types T1 and T2, I put them in the same class. It is purely a mental effort, which has been made. The class was identified, it is what DB people call "relation." But this is too little efforts to me.
>> The problem is elsewhere. How do I know in *advance* that the result of
>> join is a relation of certain narrower kind? Both "statically untyped" SQL
>> and "dynamically untyped" fancy languages have no answer to that until run
>> time. Note that this is a software design issue.
>>
> The result is what it is. If it answers the messages sent it
> predictably what does it matter?
How can you predict it? To answer to messages in a certain way is a behavior. Let's denote it T. Now, the question is about ~T. Do all possible objects expose T, so that ~T be empty? I bet some don't. Now, because T is not statically determinable we could not predict T. That matters.
Clearly we cannot map all behavior to types in order to statically ensure it. But we have always try to do it as much as possible. Giving up without even a try is a bad idea from software design point of view.
-- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.deReceived on Wed Mar 05 2008 - 21:10:11 CET