Re: Mutability
Re: Mutability
- Subject: Re: Mutability
- From: Ondra Cada <email@hidden>
- Date: Wed, 21 Nov 2001 18:16:27 +0100
Julien,
>
>>>>> Julien Dufour (JD) wrote at Wed, 21 Nov 2001 17:48:42 +0100:
JD> Typing would limit the set of messages you can send to an object during
JD> compilation. So when an object A is given to object to another object B,
JD> the compiler would know what are the requirements for A (defined by B),
JD> and verify that you only pass objects that can be handled.
That's the idea... which does not work. The compiler _CAN'T_ know whether in
reality (in run-time) the object which is sent those messages is A indeed or
not.
Besides, the compiler can't even know which messages A understands, since it
is determined dynamically as well! There can be an A category (or
posedAsClass) added. A can, too, just re-direct messages to another object,
whose class is unknown at the runtime. Etc, etc.
JD> For example, you write a piece that reverse the order of the elements of
JD> a list.
Right, that's a very nice example. Since...
JD> This piece has two requirements:
JD> - the argument must be a list.
JD> - the list must be mutable.
...both those presumptions are wrong!
JD> It would be a non-sense to give a window or a non-mutable object to this
JD> piece of code.
It would not.
First, the window: it might contain a list to which it re-directs all
messages it does not understand itself. You would probably (?) advocate that
the proper way of doing that is this:
id aWindow;
id aList;
...
// I'll use functions here to keep the questioned object in argument -- in
practice it would be better to make it a message receiver:
reverseList(aList);
reverseList([aWindow list]); //(*)
Did I guess properly?
Well, the problem with this approach is that it bounds you too tightly to
the current situation: you lose flexibility.
The proper way of doing that is saying: "reveseList's argument can be any
object which understands -count, -objectAtIndex:, and
replaceObjectAtIndex:byObject:" (or something like that) ", otherwise it
raises an exception".
What "kind" (type, class) of object it really is is absolutely unimportant.
It can be a NSMutableArray of course (quite probably the most often
solution); but it can be a very special list of mine, NSObject's direct
subclass with a specific implementation and just the needed API, or the
aforementioned window which redirects messages to its internal list, etc.
As for mutability: letting alone that in some cases it might be desirable to
make a mutable copy of an immutable argument (this case I described in one
of my previous mails), there's a much simpler thing:
_Whenever the argument represent an empty list or a list of exactly one
item, or a list which is symmetric (item[k] isEqual:item[N-k+1]), the method
should do nothing_.
Especially, it should work properly on such lists regardless they are
mutable or not!
JD> Typing makes the compiler able to warn you when you are
JD> doing such a non-sense. Handling this is easy at compile time: you
JD> change your code so that it can never happend.
Again, nope: with this kind of compiler support, you _THINK_ it can never
happened, and consequently you change your code so that as soon as it happens
-- and it *WILL*, in any real-world, distributed,
more-complicated-than-tic-tac-toe thing -- all hell will break loose.
JD> ...Handling this at runtime is difficult:
Agreed, but it's the *ONLY* way to make your code robust, easily debuggable,
easily maintainable, and easily upgradeable.
JD> you have to find a way to raise to error up, and
JD> you have above all to handle such errors!!!
Not really: with proper runtime support (like the ObjC one is) and properly
designed libraries (like the OpenStep ones were) you can leave all errorneous
situations unchecked -- they will raise an exception "by default", thanks to
the runtime.
JD> C++ is an OO langage has much as ObjectiveC.
That's a widely spread misunderstanding. C++ does not even support
polymorphism properly: make two classes which are not in one inheritance
branch, implement _the same_ method in both, and try it. You'll be surprised
;)))
JD> >Am I completely wrong here? If so, why?
JD>
JD> You are not completely wrong. I have just been influenced by the Cocoa
JD> actions mecanism, and you try to use it everywhere. At the first look,
JD> actions look great, especially for the menus management. However,
JD> actions should be typechecked two, it would make the developer work
JD> easier.
Again, quite the contrary. Actions are just a special case of using the
generic OO system; and how would you want to typecheck them?!?
---
Ondra Cada
OCSoftware: email@hidden
http://www.ocs.cz
2K Development: email@hidden
http://www.2kdevelopment.cz
private email@hidden
http://www.ocs.cz/oc