Re: Private, Protected methods in Obj C?
Re: Private, Protected methods in Obj C?
- Subject: Re: Private, Protected methods in Obj C?
- From: <email@hidden>
- Date: Thu, 4 Apr 2002 00:12:07 -0000
"Erik M. Buck" <email@hidden> said:
>
It is also worth noting that a determined programmer can also get around C++
>
private virtual member function restrictions. Private virtual member
>
functions are still in the class's vTable and can still be called with the
>
correct index into the table. Systems like Microsoft's COM are quite
>
capable of calling member functions and the compiler can not stop them.
Yes, the private/protected scheme in C++ is provided to aid the developer in
sticking to his own encapsulation design, and does not preclude anyone from
working around the restrictions.
>
>
In Objective-C, "private" methods are hidden from users of the class. If
>
the user is determined to find out what the "private" method's selector is
>
and call it anyway, there is nothing that can be done. Determined
>
programmers can circumvent anything.
>
>
----- Original Message -----
>
From: <email@hidden>
>
To: <email@hidden>
>
Sent: Wednesday, April 03, 2002 3:01 PM
>
Subject: Re: Private, Protected methods in Obj C?
>
>
>
> In a message dated 4/3/02 12:14:24 PM, email@hidden writes:
>
>
>
> >This is close to private methods in C++. Not not sure about an
>
> >equivalent for protected methods
>
>
>
> I believe that the methods are still public, but if they aren't visible
>
> publicly, then nobody knows to use them. This means that they will still
>
be
>
> inherited, and so they are actually similar to protected methods. Private
>
> methods can't really be achieved, though they are generally unnecessary.
It's interesting that this came up because I was just thinking the other day
about the similarities between Objective C selectors and Dylan's generic
functions, and the analogy is relevant to this discussion.
In Dylan, methods are not a part of the class at all. You define generic
functions that act on the object arguments and then you add methods for
particular classes. This is like the selectors in Obj C except in Dylan the
actual method chosen can depend on the types of all of the arguments
(multiple dispatch) whereas in Obj C the method chosen for a particular
selector is determined by one agrument, the object receiving the selector.
Anyway, in Dylan you can define new generic functions on classes outside the
module where the classes were defined, which is analogous to categories in
Obj C. And so forth.
The relevance to this discussion is that the generic function name in Dylan
does not belong to any particular class. In Obj C, the selector name does not
belong to any particular class, which is where some of the power of Obj C
comes from, you can invoke an selector an object without even knowing which
class hierarchy it belongs to.
In C++, the method name is tightly bound to the class, so you can implement a
private/protected scheme. Really, two methods with the same name but in two
different class hierarchies don't really have the same name in C++, because
they belong to two different namespaces (using namespace in the general sense
here, not as in the C++ namespace keyword), so it is possible to have one be
public and the other be private. In Obj C, selector names are global -- they
don't belong to any particular class or namespace, so this is why a
private/protected keyword for Obj C doesn't really make sense.
Although I don't feel the crying need for private methods in Obj C myself (I
find the technique of not declaring them in the interface to be satisfactory)
it might be interesting to speculate how the language could be extended to
add this feature. Now, in Dylan things are declared in modules, and that's
the protection mechanism, so if you don't export a generic function name then
it remains private to that module. Then, even if the function is declared
outside the module, it is really a different function. In a way, there is a
global namespace and then each module has its private namespace, so any
identifier that is explicitly exported becomes part of the global namespace.
The closest thing to a module in Obj C is simply file scope, so I guess you
could do something similar by declaring a selector private to that file. Then
it would be like a static function, and would really be a different selector
from the "global" selector. In that case though, you couldn't even override
it unless you implemented the superclass overriding the method in the same
file. In practice, this sort of thing doesn't seem much more useful than just
using a static function.
- Dennis D.
_______________________________________________
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.