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 18:49:02 +0100
Sorry, I'm not as uch experienced as you are in Objective-C, but I
disagree with your answer to I. Gomez. You give the feeling that Obj-C
lacks some features that Java/C++ have. The thuth is, Obj-C IS different,
and a newbie must learn the way it works (as for any language), NOT TRYING
TO USE IT THE SAME WAY other languages do.
Le mardi 19 mars 2002, ` 12:33 , Alex Raftis a icrit :
On Monday, March 18, 2002, at 12:24 PM, Ivan Gsmez wrote:
Yes but that is not the way when for example, you are creating (as I'm
doing now) and Element class which will be inherited by Cube, and
Sphere and others and you want to inherit the position parameters and
force the derived class to implement the Draw method. I think the
simplest and
more common example in every OO book.
Consider it this way. Obj-C, being so dynamic, this check should be done
at runtime. So, implement the method in the parent class like:
(...)
This is the only safe way in Obj-C to handle abstract methods, since the
method can come from anywhere at any time since Obj-C (with Apple's
extensions) supports categories and dynamically loading code at run time.
NO NO NO! Don't do that! First of all the example is silly. But even for
a true example, like say the NSString class which is "abstract", with a
lot of "concrete" subclasses, you should not do it that way. That's the C+
+/java paradigm! Apple don't do that this way, so follow the example of
the Foundation/AppKit classes. This is called a "class cluster", and you
cannot have that in C++ or Java, so you don't find it "in every OO book".
In Obj-C, you write the header of the "abstract class" AS IF it were
concrete (see NSString, NSDictionary, etc.). It has all the required
method, including init... ones, etc. You don't even need to mention that
it is an abstract class. Then you write the concrete subclass (possibly
hidden in the .m file). The trick is that the programmer is supposed to
instantiate the class through one of the init method (using the standard
construct [[MyParentClass alloc] init]); one of the great feature of Obj-C
(I forgot that one yesterday) is that IT DOESN'T HAVE CONSTRUCTORS, that
is "init" is a method among others. Why is it great? Because it allows you
to create and return an object of a different class in the init method
(that the very reason why init returns "id", not "MyClass*"):
@implementation MyParentClass
-(id) init {
[self release]; // trash the allocated object created by
[MyParentClass alloc]
return [[MyConcreteSubClass alloc] init];
}
Do you see the point? The programmer don't have to bother with "abstract"
things, and don't have to care. (The only exception is for subclassing,
which need a little care.) You can differentiate upon different init
methods, etc. Much simpler and flexible than the C++ way.
(Note: You can improve the code above, because you can override
[MyParentClass alloc], too. It doesn't need to create a new object each
time, since this object is only temporarily used as a proxy for the init
method. Note in the note: override allocWithZone, not alloc.)
-How do I make a variable "public static final" (as in Java)
on Objective C. I have try with const but I can initialize it?
Obj-C does not support class variables. Then again, Java is basically
implementing your above code as "const". There's a couple of ways to
deal with these.
1. Use #define and treat the values as macros.
Better write:
const int myConstant = 12;
Less error prone than macros. Doesn't work with objects, though. Use the
other way. If it is very important that the object cannot be changed, use
immutable classes (again look in Foundation for the way to do that). These
ones are actually more useful than just providing constants. Note that
usual classes like NSString, NSNumber, NSArray, NSDictionary, are all
immutable for this reason among others.
And are "+" methods available to other classes without having to
instantiate then. Just as having a math class and call sin (x). You
don't need to instantiate a Math class to calculate a sin.
What a good example of a stupid limitation of Java. Who wants to type Math.
sin(x) for every call to the sinus function? What the hell does this
standard function have to do with OOP? (If you don't know Java, let me
tell you: you REALLY need to type Math.sin(x), because there is no shorcut,
no "using", no "macros", etc. Boring as hell, particularly when doing
maths.)
To clarify a little for the Java mind set. A '+' method in Obj-C is both
a factory method and a static method. However, you must remember
that '+' methods can be over ridden, which seems to be a slightly odd
idea to C++ and Java developers. Basically, Java doesn't have true class
method, since class methods are basically just a way to implement
functions.
If you want pure Java type behavior, implement your + method like:
NO again! If you want a pure function with no derivation at all, that
means that you need a standard C function. So define it that way:
extern float myFunction(float x);
That's really what C++ does, it just allows a slightly different syntax
like AClass::aStaticFunction().
-How do I make an method private or protected?
As others have pointed out, you don't. The problem is that this wasn't
designed into the language by default.
Is that a problem? Whenever I need a "private" method, I put it in the ".m"
file, and give it a special name. I never had any problem with that way
of doing.
Once again, abstract can't be enforced by the compiler, because the
language is so dynamic. The compiler actually has no way of know what
frameworks, libraries, or bundles will be loaded at runtime, therefore,
it has no way to determine what methods haven't been implemented. As I
mentioned above, the best solution for this seems to be throwing
exceptions in methods that should have been implemented by the
developer. Following this logic, an all methods on an abstract class
throw exceptions. Still, an abstract keyword might be nice, since it
would allow the compiler to flag a potential problem.
No. There is not need of abstract classes in the whole Foundation/AppKit,
so there is probably no need at all for them. See previous discussion on
class clusters.
My one desired feature, of those you mention above would be operator
overloading. Still, given some of the abuses of operator overloading
I've seen, I don't miss this all that much.
Since Obj-C don't use directly the objects, but rather pointer to objects,
it doesn't make sense to use operator overloading for Obj-C. The only
interesting use of operator overloading I know of are for more-or-less
mathemtical objects (like the complex C++ class). These would not make
sense to use as Obj-C objects, since they are not dynamic at all, and they
can be used in Obj-C++ exactly the same way as in C++.
Standard C function overloading would be useful, though, as well as (some
sort of) namespaces. Anyway both are permitted by Obj-C++, so it is not a
big deal.
--- Thomas LACHAND-ROBERT ---
Laboratoire de mathimatiques de l'universiti de Savoie
(LAMA :
http://www.lama.univ-savoie.fr/)
Page personnelle :
http://www.lama.univ-savoie.fr/~lachand/
_______________________________________________
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.