RE: [Q] omissible method declaration in interface file
RE: [Q] omissible method declaration in interface file
- Subject: RE: [Q] omissible method declaration in interface file
- From: Erik Buck <email@hidden>
- Date: Sat, 27 May 2006 12:19:35 -0400
Well... isn't it be controlled by @private, @protected, and @public?
No. @private, @protected, and @public apply only to instance
variables and not instance methods. As a practical matter, @private,
@protected, and @public cannot be enforced even for instance
variables at run-time because an instance can always be treated as a
C struct via @defs(class_name) and the variables can be accessed
using simple C structure dereference.
It would be better to prevent errors related to wrong declaration of
methods in a class, if method declaration is not omissible.
What makes you think so ? Have you ever used a dynamic programming
language like smalltalk, or lisp ?
What is the definition of "wrong" ? The declaration is what it is.
Also, it would be more helpful to understand existing codes which
is not
written by yourselves.
In what way ? If certain methods are just implementation details of
a class, why do you need to know that they exist at all ? How does
it help you to know that a method is private compared to not knowing
it exists ? How does a mere declaration in an interface tell you
anything useful that class documentation and/or access to the
implementation does not tell you ?
If things are omitted in interface files and they
are written in their implementation files, it would be easy to lose
track, and although some methods are deleted accidently from the
implementation file, it would be easier to figure out which one is
omitted or not.
By default, an Objective-C compiler will WARN you that a method is
declared but not implemented. Implementing a method that is not
declared is not even worth a warning. It is normal.
Probably there is reason the Obj-C was designed this way.
There is. Objective-C is a dynamic language. Objective-C achieves
dynamism by allowing any message to be sent to any object. @private,
@protected, and @public don't make sense for methods because they
directly contradict the ideal that you can send any message to any
object. Furthermore, enforcing @private, @protected, and @public
would have to be done at run-time and therefore reduce messaging
performance because the compiler can never know what messages may be
sent at run-time.
See http://developer.apple.com/documentation/Cocoa/Conceptual/
ObjectiveC/Articles/chapter_4_section_6.html
Consider that you can write a program that accepts a string input by
the user, converts that string to a message selector via
NSSelectorFromString() and sends that message to an arbitrary object
in the program.
Consider that a message may be forwarded to a different receiver via
the Objective-C run-time and NSObject and NSProxy classes. Consider
that the receiver of a message may not even be in the same program
that sends the message. How would a compiler enforce that ?
See forwarding and remote messaging topics in "The Objective-C
Programming Language"
Consider that you may be using the Python to Objective-C bridge,
PyObjC, and the messages sent to objects are not known until the
Python program is executed.
Consider that methods can be added to existing classes at run-time!
So, why use a dynamic language ?
See "Why Objective-C"
http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/
Articles/chapter_2_section_1.html
Here are some specific reasons:
- Greatly reduced "Fragile Base Class" problem. What's the Fragile
Base Class (FBC) Problem? http://homepage.corbina.net/~maloff/holy-
wars/fbc.html
- Easy bridging between dynamic languages. http://www.fscript.org/
links.htm
- One syntax for messaging both local and remote. No COM/DCOM/
ActiveX/IDL needed.
- No need for C++ style templates.
- Simple and prowerfull introspection. NSClassFromString(),
NSSelectorFromString(), @defs(), class_addMethods(),
class_getInstanceVariable(), etc.
- Target/Action paradigm.
- Delegates
- Cocoa Bindings
- Anonymous objects
See Closed-World Applications vs. Open-World Applications at http://
www.informit.com/articles/article.asp?p=29979&seqNum=5&rl=1
"Some programmers are just more comfortable solving closed-world
style problems and might never be satisfied with Cocoa because it is
designed to solve open-world problems."
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden