Re: Several questions on Objective C
Re: Several questions on Objective C
- Subject: Re: Several questions on Objective C
- From: Thomas Lachand-Robert <email@hidden>
- Date: Tue, 19 Mar 2002 23:08:24 +0100
Le mardi 19 mars 2002, ` 10:06 , Alex Raftis a icrit :
I present it this way, because that's how most people need to learn the
language. I've actually had quite a bit of experience with moving people
from C++ (and Java) to Objective-C. If you try to get them to throw
everything out, they won't listen. You have to get them to adapt their
current knowledge to the new language.
I understand this, but I think many people in the list are still stuck
with C++/Java paradigm. I don't like the reference to "every OO book" from
Ivan, because that usually means "books on Java" (or worse C++).
That was my main point, I didn't intend to flame you. We all appreciate
when some experienced people try to explain something to newbies, at least
I do, because I always learn something then (even when I disagree on some
points ;-)
You are probably right that this sort of hightly detailed points are not
easy to newbies, but on the other hand that's this sort of subtle
difference that makes Obj-C much more enjoyable than Java. (Something
similar about the difference between a mac and a W$ machine.)
Besides, most of what was asked are pretty much standard object oriented
principles, and Obj-C can implement those, with a slight change in mind
set.
Maybe not so slight ;-)
Actually, this is exactly how Apple does it. Create a subclass of
NSString and call length or characterAtIndex:. Both methods will throw an
exception indicating that you need to implement the abstract methods in
your concrete subclass. Class clusters are just a design style to
implement abstract (or partially abstract) classes in Obj-C. The other
concrete classes in NSString use these abstract methods to get their work
done.
I was a little bit confuse here, but I mean that a programmer don't need
that. If none of the init methods of the abstract class does actually
return an instance of the abstract class, it is not even necessary to
implement them except to avoid compiler errors. And there is no need to
throw an exception. Actually the abstract class can implement a default or
partial behavior for the subclasses, they are free to use it or not. As I
said, it is a little bit different if someone derive a new class from the
abstract class without care. IMHO Apple should not throw an exception in
NString length default method, but return 0 (that is, the length of the
strings in the abstract class are zero). Then, characterAtIndex: has to
throw an exception because every index is wrong.
I won't disagree with you there, expect to say that Obj-C does have
constructors, they're just implemented in a more generic, flexible
fashion than C++ or Java, in that, as you say, you can return a value
from a constructor*.
That's pure semantic, but these are not constructors. They are methods you
are supposed to call before others. C++ and Java have constructors, that
is, special functions with a particular behavior and syntax. Similarly
Obj-C doesn't have destructors, because dealloc is an ordinary method.
In effect, once again, Obj-C works by convention, not by enforcing rules
in the compiler. This is very flexible. In fact, when I work in Java, I
often implement a single constructor (equivalent to alloc), and then use
init methods, since these can then be used in a more generic fashion. It'
d work really great if Java would just support a "void" type like "id".
Isn't that java.lang.object? Such a thing doesn't exist in C++, which is a
really big mistake.
But you miss the point. The programmer does have to worry about
implementing abstract methods. NSString, NSMutableString, NSArray,
NSMutableArray, NSAttributedString, NSMutableAttributedString,
NSDictionary, etc.. all have abstract methods that must be implemented by
subclasses.
Again, I was confuse. I meant that the programmer USING the classes doesn'
t have to care. He is usually different from the programmer DEFINING the
classes. Many Cocoa programmers don't even know that NSString is "abstract"
and don't care. They USE it in their programs as a concrete class. That's
very different from C++/Java where even the "programmer-user" has to deal
with abstract things defined in standard librairies. In other words, Obj-C
hides the complexity of abstract class as an implementation detail who
appears only to subclassers.
Now, don't get me wrong. I love Obj-C and I use it as my primary language
whenever I have a choice in the matter. I hate using C++. I don't really
even consider it an object oriented language, because it's missing so
many features of a fully mature OO language, like run time binding. Java
is better, but it's taken them four revisions to realize how useful
dynamic binding really is. Java is just now really starting to
concentrate on making their reflection libraries more usable.
Java is not intended to build applications, but to build applets. Java is
great for applets, and bad for applications. I don't think it's going to
change, but who knows?
One of the most surprising thing about Java, is that it's learning curve
is much longer than Obj-C's, but at the end it doesn't really give
something more.
My tact, when addressing Ivan's questions was that people who are coming
from another OO language, like C++ or Java, must first learn to apply the
OO principles they learned from those languages in Obj-C. Once they've
learned those, then they're ready to explore the whole new world opened
up by Obj-C.
That's here that I disagree. Coming to a new world, learn new methods.
Otherwise you get bad habits. Just my own principle...
Yes, they will have to unlearn some principles, like templates (which are
only a hack to make up for the lack of run time binding), but most OO
principles in C++ are valid and do apply to Obj-C.
No, templates are useful also to limit code duplication. (Think about
complex<float> vs. complex<double>.) Something you can do with macros, but
it is more complicated and dangerous.
Thomas Lachand-Robert
********************** email@hidden
<< Et le chemin est long du projet ` la chose. >> Molihre, Tartuffe.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.