Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP and memory management

From: Niklas Matthies (usenet-nospam_at_nmhq.net)
Date: 07/28/04 

Date: 28 Jul 2004 14:21:04 GMT

On 2004-07-27 00:10, Thomas Gagne wrote:
> Michael N. Christoff wrote:
:
>> This makes no sense, to me at least. How is the user of some
>> software 'always' more knowledgeable than the person who wrote it?
>> This implies that before you send an object to another bit of code,
>> you have to analyze the receiver to the point where you know more
>> about it than the authors themselves. Seems like a waste of time
>> to me, when we could simply have the receiver specify what objects
>> are appropriate. ie: everyone takes responsibility for their own
>> code. Its almost a restatement of the idea behind encapsulation.
>> My object has a protected state and I (the receiver) take
>> responsibility for protecting that state. I do not pass off that
>> responsibility to the users of my code. Also, there is the whole
>> issue of the use of commercial closed source software where there
>> is no way the sender could be more knowledgeable about the receiver
>> than the receiver itself.
>
> They don't have to know the receiver inside and out--only enough to
> know what it's supposed to do, then they should be able to send it
> anything that meets the /minimum/ requirements.

The problem here is that changing the receiver's implementation
without breaking any possible existing senders becomes quite
problematic because the receiver must behave exactly as before in
_all_ conceivable aspects, instead of merely maintaining the published
(declared) behavior.

This philosopy of defining the contract between sender and receiver in
terms of the receiver's implementation makes it very difficult to have
a working seperation of interface and implementation.

-- Niklas Matthies

Relevant Pages

  • Re: Client/Service relationships & Flow of Requirements.
    ... the Receiver is making a demand on the Sender This requirement cannot be adequately stated in DbC. ... The Observer has an obligation to provide an implementation of an 'update' responsibility when the application solution needs it. ... That vision caused the developer to decide that an 'update' behavior responsibility was needed to solve the problem and the logical owner of the responsibility would be a particular problem space entity abstracted as an object. ...
    (comp.object)
  • Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP and memory management
    ... > "It is not the responsibility of the receiver to determine the qualities ... > the sender, but the privilege of the sender to determine the suitability ...
    (comp.object)
  • Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP and memory management
    ... > "It is not the responsibility of the receiver to determine the qualities ... > the sender, but the privilege of the sender to determine the suitability ...
    (comp.programming)
  • Re: Neutral Format as a Coupling reduction idea that doesnt work.
    ... There are potentially unlimited and unexpected side effects for both sender and receiver. ... That definition defines the semantics of the just the data packet. ... That represents a solution level coupling but at least it is very narrowly focused on the message definition rather than what each side does with the information. ...
    (comp.object)
  • Re: PostMessage and unprocessed messages
    ... The sender has no way to know when to delete the message, so making it the owner has no ... Since the receiver would have no way to know the message is deleted, ... collection, note that as long as something is in the queue, it is owned by the queue ... so adding memory management complexity to the ...
    (microsoft.public.vc.mfc)