Re: Mutability
Re: Mutability
- Subject: Re: Mutability
- From: Julien Dufour <email@hidden>
- Date: Wed, 21 Nov 2001 17:48:42 +0100
On Wednesday, November 21, 2001, at 02:57 PM, Ondra Cada wrote:
Julien,
Julien Dufour (JD) wrote at Wed, 21 Nov 2001 06:59:05 +0100:
JD> I think you have a wrong approach. You shouldn't have to test
whether or
JD> not objects you manipulate are mutable version. Your code should
"know"
JD> what kind of object it manipulates.
I beg to differ. It seems to me that the proper OO approach is "give
any id
to me; I'll ask it what kind it is, and I'll behave accordingly".
This has really nothing to do with OO. This is typing domain. Objects
design pattern is a tool here, and Cocoa uses object reflexivity to work.
With ids, you can send any message to the object, then your code has to
check if thing are going well. It can do it by checking the kind of the
object (that define the set of authorized messages) or with reflexivity
to check that a given message is accepted (Apple's way, with selectors).
Typing would limit the set of messages you can send to an object during
compilation. So when an object A is given to object to another object B,
the compiler would know what are the requirements for A (defined by B),
and verify that you only pass objects that can be handled.
"I'll behave accordling" is a strange design. The involved piece has a
role, an action to complete. You can not change its role depending of
the arguments, your code would be really difficult to understand...
Write two pieces and use the right one.
For example, you write a piece that reverse the order of the elements of
a list. This piece has two requirements:
- the argument must be a list.
- the list must be mutable.
It would be a non-sense to give a window or a non-mutable object to this
piece of code. Typing makes the compiler able to warn you when you are
doing such a non-sense. Handling this is easy at compile time: you
change your code so that it can never happend. You may have to change a
lot of code, but that proove that your design was bad. Handling this at
runtime is difficult: you have to find a way to raise to error up, and
you have above all to handle such errors!!!
The approach you advocate here -- ie. "give me an object we both know
beforehand which kind it is" seems to me like non-object-oriented,
C++-way of
thinking.
C++ is an OO langage has much as ObjectiveC. ObjectiveC simply offering
reflexivity, that is a powerful tool in OO world, but a dangerous one
too.
Am I completely wrong here? If so, why?
You are not completely wrong. I have just been influenced by the Cocoa
actions mecanism, and you try to use it everywhere. At the first look,
actions look great, especially for the menus management. However,
actions should be typechecked two, it would make the developer work
easier.
The discussion could last really long. I suggest you to read some book
about OOP where those problems are often treated.
--
Julien Dufour