Xref: utzoo comp.object:1013 comp.lang.c++:6701
Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!pt.cs.cmu.edu!andrew.cmu.edu!bader+
From: bader+@andrew.cmu.edu (Miles Bader)
Newsgroups: comp.object,comp.lang.c++
Subject: Re: Objective C vs. C++, Recommendations?
Message-ID: <MZvjQrG00Vsa83ezEc@andrew.cmu.edu>
Date: 2 Mar 90 22:44:07 GMT
References: <1535@dinl.mmc.UUCP>,
	<44039@ames.arc.nasa.gov>
Organization: Information Technology Center, Carnegie Mellon, Pittsburgh, PA
Lines: 60
In-Reply-To: <44039@ames.arc.nasa.gov>

Just for fun, here are my six favorite icky bits in Objective-C 4.0 on the
next machine, circa January 1989:

1) It currently uses a single namespace for method templates, regardless of
    the type of the receiver.  This results in warnings when two (totally
    independent) classes use the same method name but with different argument
    or return types.  It *should* warn only if the type of the receiver is a
    superclass of the two classes with conflicting methods (such as when it's
    an id).  This is VERY IRRITATING, as extremely common cases result in
    this (e.g. [Float create:1.0] & [Int create:1]).

2) It currently uses a single namespace for the instance variables of an
    object of a given type AND all its superclasses' instance variables.
    Instance variables should be known only to the implementation of a class;
    its subclasses shouldn't have to worry about name-clashes with their own
    instance variables (and conversely, shouldn't have such easy access to
    their superclasses instance variables).

3) It should not warn about implicit casts from a type to one of that type's
    superclasses.  (e.g.  Object *foo=[SubTypeOfObject new]; should elicit no
    warnings).  The c-compiler seems to be doing the complaining, so
    objective-c should put real casts into the c-code it outputs.

4) There should be a pseudo-type that is always the same as the type of the
    receiver at compile time, so that methods inherited by a subclass that
    return (or have an argument of) that type don't have to be unnecessarily
    casted, in cases where it doesn't make sense to do so.  Example:

	@interface A {}
	-(ReceiverType *)self;  // stupid method just returns self
	@end

	@interface B : A {}
	// inherits the self method from A
	@end

    One can then do:
	{B *var1=[B new], *var2=[B self];}
    without warning messages.  One can acheive this by using the (id) type,
    but at the expense of compile-time type-checking in these cases.  Indeed,
    the +new class method in Object should probably return (ReceiverType *).

5) Apparently, a unique, global symbol is declared by the objc
    pre-processor in each file, with a name constructed from the
    filename.  This prevents users from using filenames that are the
    same as any filename used in the objc library that ends up being
    linked!  It doesn't actually give an error to this effect, you
    just get a multiply defined symbol error from the linker.  Users
    definitely shouldn't have to worry about name-clashes with the
    filenames used in the objc library!

6) If you reference a class by using it as a type in it's own include
    file, objective-c uses the contents of the instance variable
    declaration block as the contents of TWO structures in the
    resulting include file.  This breaks if any of the instance
    variables are non-anonymous structures (as it results in declaring
    those structures twice).  As NeXT include files often contain such
    non-anonymous structures in their instance variables, this shows
    up frequently for me.