Re: Mutability
Re: Mutability
- Subject: Re: Mutability
- From: John Hörnkvist <email@hidden>
- Date: Wed, 21 Nov 2001 18:08:04 +0100
On Wednesday, November 21, 2001, at 04:37 , Julien Dufour wrote:
On Wednesday, November 21, 2001, at 02:57 PM, Ondra Cada wrote:
So far as I understand OOP, the proper OO point of view is "give _any_
object to me; I'll determine what kind it is, and I'll behave
accordingly".
That's not OOP, that untyped langage programming.
Well, it's dynamically typed programming. That's quite different from
untyped programming.
Assembly is untyped programming. Lisp, Smalltalk, Objective-C and many
others are dynamically typed.
In a fully statically typed language, type information is not needed at
run time, and can be thrown away by the compiler. In a dynamically typed
language, the runtime makes decisions based on types, and that
information has to be preserved.
[Delete]
DMC> Really, using things like "isKindOfClass" is often a symptom of
bad
DMC> design.
Is it?!? I'd say it is a symptom of _THE PROPER_, ie. run-time design,
as
compared with the bad, C++-like compile-time one!
No it's really not. You are recommending untyped langage instead of
typed ones. Typechecking is compilation stage where the compiler tells
you if you are doing something wrong.
Rather it tells you that you _might_ be doing something wrong. For any
language and type system, there will be correct programs that cannot be
given a static type.
Stronger typesystems lead to robuster programs. With the ""give _any_
object to me; I'll determine what kind it is, and I'll behave
accordingly" philosophy (untyped philosophy), anything can happend at
runtime. You then have to produce much more complex code to check what
happend and to handle invalid cases... etc. You do compiler's work here
(aren't computer there to work instead of us).
But compilers cannot do it in all cases.
This work SHOULD be done by the compiler. It won't commit mistake (but
you will), it is automatic, you save time and work, and you procuce
more safe code, you have less to debug! Moreover, your code will be
much faster as lot of tests are not needed anymore, and many
optimisations are made possible.
That requires a type system that doesn't have paradoxes built in.
Objective-C does not have such a type system.
Consider:
-(id)init;
+(id)alloc;
You almost never get an object that has a sound static type!
Thanks to dynamic dispatch, dynamic typing and conventions outside the
formal type system, it is possible to write sound Objective-C programs
anyway.
The dictinction between mutable objects and not mutable ones, even if
the same objects are used behind (I think it is the case, but we do not
have to know, that's implementation, not interface!), is a really good
thing. It uses as much as possible the poor capabilities of
ObjectiveC/Java type systems.
Except that it robs us of some type information that can make the
program more robust at run time.
A strong and coherent static type system would be wonderful, but adding
it to Objective-C at this point seems close to impossible; the effects
on existing code would be tremendous. In the absence of strong static
typing, it makes sense to make use of the dynamic type system where
possible.
Regards,
John Hornkvist
--
ToastedMarshmallow, the perfect Cocoa companion
http://www.toastedmarshmallow.com