Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

Bruno Desthuilliers wrote:

> Bob Badour a écrit :
>

>> Bruno Desthuilliers wrote:
>>
>>> Marshall a écrit :
>>>
>>>> Joe Van Dyk wrote:
>>>>
>>>>> frebe73_at_gmail.com wrote:
>>>>>
>>>>>> But there are many (enterprise) applications there OOAD is not
>>>>>> suitable. Some OO languages (such as java) has disadvantages because
>>>>>> they don't allow first-order functions and function pointers.
>>>>>
>>>>> I don't know Java, but if your statement about Java disadvantages is
>>>>> true, that's a problem with Java -- not with OO.
>>>>  
>>>> It is simple, if not particularly convenient, to use what are
>>>> essentially
>>>> first-order functions and function pointers in Java. However,
>>>> the fact that you have to fake it illustrates why OOP is merely
>>>> a useful point of view that works a lot of the time, as opposed
>>>> to a true foundationally complete approach to programming.
>>>
>>> Have mercy, stop confusing Java with OO. I do OO everyday, and could 
>>> not live without HOFs. 
>>
>> Bruno, the fact that some OO has HOFs and some OO does not supports 
>> Marshall's observation.

Yes, I understood that perfectly. However, it is an OO language as are a number of other OO language that lack HOFs. By your definition Simula would cease to be an OO language, which is absurd.

One does not build a sound foundation by the ad-hoc addition of features.

>>>> Don't get me wrong; I really like OOP and it's what I use
>>>> when I need to program. But don't mistake its usefulness
>>>> for profundity. OOP has some deep problems, and some
>>>> of its features, like encapsulation and inheritance, will be
>>>> sloughed off when better techinques become widely available.
>>>
>>> Dynamic typing + real support for automatic (yet controlable) 
>>> delegation, and you don't need inheritance no more (still can use it  
>>> - as an implementation detail - when it's convenient).
>>
>> Are you agreeing with Marshall that encapsulation and inheritance are 
>> unecessary?

Since I am unaware that I ever made that mistake in the first place, I find your command absurd.

  What I'm saying is
> that data-hiding is not necessary, and that only declarative static
> typing and lack of support for delegation makes inheritance so
> over-abused in brain-dead languages like Java.

The truth of the matter is that while data-hiding may not be necessary, information-hiding is a very sound engineering technique justified by the principle of the separation of concerns.

As for the rest, you are only adding further support to Marshall's observation that OO falls short of providing anything resembling a sound foundation to programming.

>> Or are you suggesting that one should mistake whatever usefulness one 
>> finds in OO for profundity after all?

Don't starve yourself on my account.

>>> wrt/ encapsulation, I'm afraid you're confusing it with data-hiding, 
>>> which is not a necessary pain if you have support for computed 
>>> attributes.
>>>
>>> What about ditching Java in favor of an OO language ?-)
>>
>> What about ditching an ad-hoc computational model introduced for 
>> creating large unpredictable state machines out of small predictable 
>> state machines with predicate logic itself?

What about it? Are you proposing either the typed or untyped lambda calculus as a replacement for predicate calculus for the foundation for data management? Or are you suggesting the typed lambda calculus as providing a complete foundation to programming in a manner similar to the foundation predicate calculus provides to data management? If the latter, what about concurrency? Received on Thu Jun 01 2006 - 01:11:14 CEST