Private Methods

[Richard Charles]

Apple documentation states that the "Names of most private methods in the Cocoa 
frameworks have an underscore prefix (for example, _fooData ) to mark them as 
private.”

I just ran into a case where one of my method names in a subclass replaced a 
private Cocoa framework method of the same name causing my application to crash 
in the next version of OS X. The private Cocoa framework method name did not 
have an underscore prefix. So the documentation is correct, “most” but not all 
private methods in the frameworks have an underscore prefix.

There is no way that I would have known about the private Cocoa framework 
method except examining a class-dump.

Apple documentation also states that "If you are subclassing a large Cocoa 
framework class (such as NSView or UIView) and you want to be absolutely sure 
that your private methods have names different from those in the superclass, 
you can add your own prefix to your private methods. The prefix should be as 
unique as possible, perhaps one based on your company or project and of the 
form "XX_". So if your project is called Byte Flogger, the prefix might be  
BF_addObject:"

I have never bothered doing this because for one reason BF_addObject looks so 
ugly as a method name.

Does anyone prefix their private method names like Apple recommends when 
subclassing a large Cocoa framework class?

Also why does Apple say "If you are subclassing a large Cocoa framework class”. 
What if I am subclassing a small Cocoa framework class. What difference would 
it make?

--Richard Charles


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Private Methods

[Philip Bridson]

How do I make a method private?

I have tried putting @private before the method that I want to make  
private but the compiler flags a parse error. I read the  
documentation and I can only find reference to private member  
variables. I want to make sure that a method can only be accessed via  
another method in the same class. Is this possible in Objective-C or  
do I need to write this class in C++?


Many thanks.

Phil.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Private Methods

[Mike Abdullah]

> On 18 Aug 2015, at 15:58, Richard Charles  wrote:
> 
> Apple documentation states that the "Names of most private methods in the 
> Cocoa frameworks have an underscore prefix (for example, _fooData ) to mark 
> them as private.”
> 
> I just ran into a case where one of my method names in a subclass replaced a 
> private Cocoa framework method of the same name causing my application to 
> crash in the next version of OS X. The private Cocoa framework method name 
> did not have an underscore prefix. So the documentation is correct, “most” 
> but not all private methods in the frameworks have an underscore prefix.
> 
> There is no way that I would have known about the private Cocoa framework 
> method except examining a class-dump.

Go on, satisfy our curiosity, what did you accidentally override?


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Private Methods

[Uli Kusterer]

On 18 Aug 2015, at 16:58, Richard Charles  wrote:
> Also why does Apple say "If you are subclassing a large Cocoa framework 
> class”. What if I am subclassing a small Cocoa framework class. What 
> difference would it make?


 Statistics. Small classes probably only consist of the public API, or maybe 
even just of getters and setters. OTOH large classes are very likely to have 
more methods "under the hood" to implement all the functionality they provide.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachtText are everywhere..."



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Private Methods

[Sean McBride]

On Tue, 18 Aug 2015 08:58:22 -0600, Richard Charles said:

>Apple documentation states that the "Names of most private methods in
>the Cocoa frameworks have an underscore prefix (for example, _fooData )
>to mark them as private.”
>
>I just ran into a case where one of my method names in a subclass
>replaced a private Cocoa framework method of the same name causing my
>application to crash in the next version of OS X. The private Cocoa
>framework method name did not have an underscore prefix. So the
>documentation is correct, “most” but not all private methods in the
>frameworks have an underscore prefix.

I'm not even sure "most" is true.  A large number of Apple methods do not start 
with underscore.

>I have never bothered doing this because for one reason BF_addObject
>looks so ugly as a method name.

Me neither.  I've hit only a few conflicts over the years, in which case I 
rename.

You can set the OBJC_PRINT_REPLACED_METHODS env var to help catch conflicts.  
Always a good idea with beta version of major OS releases.

Cheers,

-- 

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com 
Mac Software Developer  Montréal, Québec, Canada

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Private Methods

[dangerwillrobinsondanger]

Hence the long traditional advice to do one or both of two things. 
Remember Objective-C has no namespaces. 
Prefix everything with your own identifier. 
Don't use short simple obvious names. 
There are many reasons Cocoa tends to be verbose. 
This is one. 

An added bonus of prefixes is that they can simplify code completion candidate 
lists!
RC_
_RC_
Three letters gets you farther away from collisions. 

What can be worse is when the runtime picks one and you don't know which one. 
And it only occasionally gets the one you don't want. 



Sent from my iPhone

> On Aug 18, 2015, at 11:58 PM, Richard Charles  wrote:
> 
> Apple documentation states that the "Names of most private methods in the 
> Cocoa frameworks have an underscore prefix (for example, _fooData ) to mark 
> them as private.”
> 
> I just ran into a case where one of my method names in a subclass replaced a 
> private Cocoa framework method of the same name causing my application to 
> crash in the next version of OS X. The private Cocoa framework method name 
> did not have an underscore prefix. So the documentation is correct, “most” 
> but not all private methods in the frameworks have an underscore prefix.
> 
> There is no way that I would have known about the private Cocoa framework 
> method except examining a class-dump.
> 
> Apple documentation also states that "If you are subclassing a large Cocoa 
> framework class (such as NSView or UIView) and you want to be absolutely sure 
> that your private methods have names different from those in the superclass, 
> you can add your own prefix to your private methods. The prefix should be as 
> unique as possible, perhaps one based on your company or project and of the 
> form "XX_". So if your project is called Byte Flogger, the prefix might be  
> BF_addObject:"
> 
> I have never bothered doing this because for one reason BF_addObject looks so 
> ugly as a method name.
> 
> Does anyone prefix their private method names like Apple recommends when 
> subclassing a large Cocoa framework class?
> 
> Also why does Apple say "If you are subclassing a large Cocoa framework 
> class”. What if I am subclassing a small Cocoa framework class. What 
> difference would it make?
> 
> --Richard Charles
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/dangerwillrobinsondanger%40gmail.com
> 
> This email sent to dangerwillrobinsondan...@gmail.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Private Methods

[Richard Charles]

> On Aug 18, 2015, at 9:01 AM, Mike Abdullah  wrote:
> 
> Go on, satisfy our curiosity, what did you accidentally override?

I made a CAOpenGLLayer subclass “context” property for use with OpenGL context 
sharing but CALayer has a private “context” property.

So yes CALayer would constitute a large Cocoa framework class (such as NSView 
or UIView). Perhaps for one reason or another there are cases where framework 
developers are not able to conveniently prefix a private method name with an 
underscore so they don’t do it.

So I tip my hat to the Apple documentation writers. In this case what they 
wrote was very accurate.

--Richard Charles


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Private Methods

[Maxthon Chan]

My own preference is to prefix private methods with underscores and the 
project’s class prefix. For example, from source code of WebUIKit (class prefix 
CGI, taken from its parent project CGIKit):

NSString *const k_CGI_PrivateMemberAttribute;

@interface CGIView ()

+ (id)_CGI_superviewWithClass:(Class)class;

@end

I believe there will be no chance for private method names clashing any more 
unless someone inheriting my class decided to keep using the CGI prefix (which 
is stupid in the first place) and keep my private method naming convention.

Or you can refactor your private methods into functions with 
CoreFoundation-like argument lists, like this (from source code of Kaleidoscope 
Event Engine, class prefix KLS):

void _KLS_RunLoopExecute(void *info) // Use self as 
CFRunLoopSourceContext->info and CoreFoundation object memory management 
functions otherwise, so I can cast pointers
{
KLSRunLoopSource *self = (__bridge KLSRunLoopSource *)info; // I am working 
with CoreFoundation which takes void pointers here. You can get away without 
this cast by putting "KLSRunLoopSource *self” equivalent directly to the 
argument list.
[self execute];
}

> On Aug 18, 2015, at 22:58, Richard Charles  wrote:
> 
> Apple documentation states that the "Names of most private methods in the 
> Cocoa frameworks have an underscore prefix (for example, _fooData ) to mark 
> them as private.”
> 
> I just ran into a case where one of my method names in a subclass replaced a 
> private Cocoa framework method of the same name causing my application to 
> crash in the next version of OS X. The private Cocoa framework method name 
> did not have an underscore prefix. So the documentation is correct, “most” 
> but not all private methods in the frameworks have an underscore prefix.
> 
> There is no way that I would have known about the private Cocoa framework 
> method except examining a class-dump.
> 
> Apple documentation also states that "If you are subclassing a large Cocoa 
> framework class (such as NSView or UIView) and you want to be absolutely sure 
> that your private methods have names different from those in the superclass, 
> you can add your own prefix to your private methods. The prefix should be as 
> unique as possible, perhaps one based on your company or project and of the 
> form "XX_". So if your project is called Byte Flogger, the prefix might be  
> BF_addObject:"
> 
> I have never bothered doing this because for one reason BF_addObject looks so 
> ugly as a method name.
> 
> Does anyone prefix their private method names like Apple recommends when 
> subclassing a large Cocoa framework class?
> 
> Also why does Apple say "If you are subclassing a large Cocoa framework 
> class”. What if I am subclassing a small Cocoa framework class. What 
> difference would it make?
> 
> --Richard Charles
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/max%40maxchan.info
> 
> This email sent to m...@maxchan.info



smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Private Methods

[Sean McBride]

On Tue, 18 Aug 2015 23:23:00 +0800, Maxthon Chan said:

>My own preference is to prefix private methods with underscores and the
>project’s class prefix.

That's exactly what you should not do.

Like the OP said, Apple's docs say that they reserve things starting with 
underscore for themselves.

Also, the C and C++ languages also reserve names that start with underscore and 
uppercase.  See ex:

<http://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier>

If you're going to use a prefix: don't start with underscore!

Cheers,

-- 

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com 
Mac Software Developer  Montréal, Québec, Canada

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Private Methods

[Richard Charles]

> On Aug 18, 2015, at 9:27 AM, Sean McBride  wrote:
> 
> You can set the OBJC_PRINT_REPLACED_METHODS env var to help catch conflicts.

OBJC_PRINT_REPLACED_METHODS logs methods replaced by category implementations. 
If the replaced method is not in a category then it does not work. :-(

--Richard Charles


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Private Methods

[Jens Alfke]

> On Aug 18, 2015, at 9:53 AM, Richard Charles  wrote:
> 
> OBJC_PRINT_REPLACED_METHODS logs methods replaced by category 
> implementations. If the replaced method is not in a category then it does not 
> work. :-(

Yeah, there’s no way for the runtime to tell the difference between an 
‘expected’ method override and an ‘unexpected’ one.

This is one of the reasons a lot of newer languages (like Swift) make you add 
an explicit “override” keyword to an overridden method declaration. That way 
the compiler and/or runtime can detect an unexpected override and issue an 
error.

But would Swift have caught this issue, since the CALayer.context property 
isn’t visible in headers at all, only in the compiled code?

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Private Methods

[Quincey Morris]

On Aug 18, 2015, at 10:20 , Jens Alfke  wrote:
> 
> But would Swift have caught this issue, since the CALayer.context property 
> isn’t visible in headers at all, only in the compiled code?

I don’t actually know (it’s a bit awkward to test), but my belief is that Swift 
does not have this defect. Conflicts within a module would be caught at link 
time, and conflicts across a module boundary can’t happen because of 
namespacing — by definition, your apparently-conflicting method name is in a 
different module.

However, it’s not obvious to me whether this works when the “base” module is an 
Obj-C framework such as Cocoa frameworks. In that case, it seems possible that 
the Obj-C mechanics of dynamic overrides might force Swift to use the older 
unsafe mechanism.

I don’t know that I’ve seen this discussed in the forums, but it would be nice 
to know the answer.



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Private Methods

[Richard Charles]

> On Aug 18, 2015, at 11:20 AM, Jens Alfke  wrote:
> 
> Yeah, there’s no way for the runtime to tell the difference between an 
> ‘expected’ method override and an ‘unexpected’ one.

How about an annotation for the compiler. Something like _Override or 
_NSOverride where you declare your intent to intentionally override a method or 
property.

Does the compiler know about Objective-C method or property overrides?

--Richard Charles


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Private Methods

[Maxthon Chan]

The compiler knows absolutely NOTHING.

It is up to the runtime to determine which implementation to call when a 
message is sent. This is the dynamic nature of Objective-C.

> On Aug 19, 2015, at 02:28, Richard Charles  wrote:
> 
> 
>> On Aug 18, 2015, at 11:20 AM, Jens Alfke  wrote:
>> 
>> Yeah, there’s no way for the runtime to tell the difference between an 
>> ‘expected’ method override and an ‘unexpected’ one.
> 
> How about an annotation for the compiler. Something like _Override or 
> _NSOverride where you declare your intent to intentionally override a method 
> or property.
> 
> Does the compiler know about Objective-C method or property overrides?
> 
> --Richard Charles
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/max%40maxchan.info
> 
> This email sent to m...@maxchan.info



smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Private Methods

[Jens Alfke]

> On Aug 18, 2015, at 11:32 AM, Maxthon Chan  wrote:
> 
> The compiler knows absolutely NOTHING.

The (Obj-C) compiler knows if a superclass declares a method with the same 
selector. So in some cases it can tell that you’re overriding. The problem is 
that it can’t tell if your method overrides a _non-public_ method in a 
superclass. That information is only in the superclass’s compiled code, not in 
the headers, so it isn’t available at compile time. (And it’s possible for the 
superclass method to be added at runtime, in which case not even the framework 
binary would show that exists!)

It would be possible to add an “override” flag to the method metadata; then 
when a class is being loaded the runtime could check whether it has a method 
without that flag that will actually override a superclass method, and if so 
signal some sort of failure. This won’t catch the cases where methods get 
inserted into the superclass after the subclass is loaded, but it will catch 
the most common causes of problems.

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Private Methods

[Charles Srstka]

> On Aug 18, 2015, at 12:20 PM, Jens Alfke  wrote:
> 
> But would Swift have caught this issue, since the CALayer.context property 
> isn’t visible in headers at all, only in the compiled code?

Jens Alfke, of mooseyard.com , has presented us with a 
poser. We do not know which bush the private method is behind. But we can soon 
find out.

MyBaseClass.h in framework:

#import 

@interface MyBaseClass : NSObject

- (void)foo;

@end

MyBaseClass.m in framework:

#import "MyBaseClass.h"

@implementation MyBaseClass

- (void)foo {
fprintf(stderr, “BOOM!\n");
}

@end

App:

import MyFramework

class MyClass: MyBaseClass {
func bar() {
print(“BLEAH!")
}
}

let obj = MyClass()

obj.foo()

Output:

BOOM!

New MyBaseClass.m:

#import "MyBaseClass.h"

@implementation MyBaseClass

- (void)foo {
fprintf(stderr, "BOOM!\n");

[self bar];
}

- (void)bar {
fprintf(stderr, "Bar called in framework\n");
}

@end

Output without recompiling the app:

BOOM!
BLEAH!

Output after recompiling the app:

No compiler errors, then:

BOOM!
BLEAH!

Yes, it was the middle one. (And also the one on the right.)

Charles

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Private Methods

[Quincey Morris]

On Aug 18, 2015, at 12:07 , Charles Srstka  wrote:
> 
>> On Aug 18, 2015, at 12:20 PM, Jens Alfke > > wrote:
>> 
>> But would Swift have caught this issue, since the CALayer.context property 
>> isn’t visible in headers at all, only in the compiled code?
> 
> Jens Alfke, of mooseyard.com   >, has presented us with a poser. We do not know which 
> bush the private method is behind. But we can soon find out.

I’m confused. We already knew the answer to the test you did — if it was 
anything else, this thread wouldn’t have ever existed.

Jens’s poser was a question about Swift. Have you tried the same test in Swift?



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Private Methods

[Alex Zavatone]

Well, the lack of adhering to that very principle was what caused my confusion 
with UIStoryboard the other day.  None of the private methods followed this.

Sent from my iPhone

> On Aug 18, 2015, at 10:58 AM, Richard Charles  wrote:
> 
> Apple documentation states that the "Names of most private methods in the 
> Cocoa frameworks have an underscore prefix (for example, _fooData ) to mark 
> them as private.”
> 
> I just ran into a case where one of my method names in a subclass replaced a 
> private Cocoa framework method of the same name causing my application to 
> crash in the next version of OS X. The private Cocoa framework method name 
> did not have an underscore prefix. So the documentation is correct, “most” 
> but not all private methods in the frameworks have an underscore prefix.
> 
> There is no way that I would have known about the private Cocoa framework 
> method except examining a class-dump.
> 
> Apple documentation also states that "If you are subclassing a large Cocoa 
> framework class (such as NSView or UIView) and you want to be absolutely sure 
> that your private methods have names different from those in the superclass, 
> you can add your own prefix to your private methods. The prefix should be as 
> unique as possible, perhaps one based on your company or project and of the 
> form "XX_". So if your project is called Byte Flogger, the prefix might be  
> BF_addObject:"
> 
> I have never bothered doing this because for one reason BF_addObject looks so 
> ugly as a method name.
> 
> Does anyone prefix their private method names like Apple recommends when 
> subclassing a large Cocoa framework class?
> 
> Also why does Apple say "If you are subclassing a large Cocoa framework 
> class”. What if I am subclassing a small Cocoa framework class. What 
> difference would it make?
> 
> --Richard Charles
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com
> 
> This email sent to z...@mac.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Private Methods

[Charles Srstka]

> On Aug 18, 2015, at 3:36 PM, Quincey Morris 
>  wrote:
> 
> On Aug 18, 2015, at 12:07 , Charles Srstka  > wrote:
>> 
>>> On Aug 18, 2015, at 12:20 PM, Jens Alfke >> > wrote:
>>> 
>>> But would Swift have caught this issue, since the CALayer.context property 
>>> isn’t visible in headers at all, only in the compiled code?
>> 
>> Jens Alfke, of mooseyard.com  > >, has presented us with a poser. We do not know 
>> which bush the private method is behind. But we can soon find out.
> 
> I’m confused. We already knew the answer to the test you did — if it was 
> anything else, this thread wouldn’t have ever existed.
> 
> Jens’s poser was a question about Swift. Have you tried the same test in 
> Swift?

Look a little closer, and you’ll notice that the app code was in Swift (like 
your app would be), and the framework code was in Objective-C (like the 
Foundation/AppKit classes are).

Charles

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Private Methods

[Quincey Morris]

On Aug 18, 2015, at 14:50 , Charles Srstka  wrote:
> 
> Look a little closer, and you’ll notice that the app code was in Swift (like 
> your app would be), and the framework code was in Objective-C (like the 
> Foundation/AppKit classes are).

Actually, I did look, but obviously I did not see.

But, in my own defense, I was looking for verification first that the mechanism 
is safe in 100% pure Swift. The next thing to verify is whether it’s safe with 
an @objc base class in Swift. Only if both those things are safe does it make 
any sense to wonder if an Obj-C base class is safe.

However, the test you did doesn’t give much cause for optimism. I suppose 
*selectors* would have to be namespaced to solve the problem for the Obj-C 
runtime, wouldn’t it? For compatibility reasons, that seems unlikely, which 
makes it unlikely that this problem will ever be solved for Cocoa frameworks.



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Private Methods

[Charles Srstka]

> On Aug 18, 2015, at 5:19 PM, Quincey Morris 
>  wrote:
> 
> But, in my own defense, I was looking for verification first that the 
> mechanism is safe in 100% pure Swift. The next thing to verify is whether 
> it’s safe with an @objc base class in Swift. Only if both those things are 
> safe does it make any sense to wonder if an Obj-C base class is safe.

Currently, the Swift runtime hasn’t stabilized yet, and it’s pretty unlikely 
that any system frameworks will be written in it until it is. So currently, 
you’re going to be recompiling everything every time, and your code will all 
have access to all Swift methods, public and private. So with pure Swift, it 
shouldn’t be an issue one way or another until Apple starts shipping a Swift 
runtime with the OS, at which point we can do a new test.

…oh heck, let’s test it now.

Framework code:

import Foundation

public class BaseClass {
public init() {}

public func foo() {
print("Foo called in library")
}
}

App code:

import MyFramework

class DerivedClass: BaseClass {
func bar() {
print("Bar called in app")
}
}

let obj = DerivedClass()

obj.foo()

Output:

Foo called in library

New framework code:

public class BaseClass {
public init() {}

public func foo() {
print("Foo called in library")

self.bar()
}

internal func bar() {
print("Bar called in library")
}
}

Results without recompiling:

Foo called in library
Bar called in app

Wat.

Results after a recompile look okay:

Foo called in library
Bar called in library

However, for more fun times, I tried deleting bar() from BaseClass and running 
the app again without recompiling. I got:

dyld: Symbol not found: __TFC11MyFramework9BaseClass3barfS0_FT_T_
  Referenced from: 
/Users/###REDACTED###/Library/Developer/Xcode/DerivedData/build/Products/Debug/new
 test.app/Contents/MacOS/new test
  Expected in: 
/Users/###REDACTED###/Library/Developer/Xcode/DerivedData/build/Products/Debug/MyFramework.framework/Versions/A/MyFramework
 in 
/Users/###REDACTED###/Library/Developer/Xcode/DerivedData/build/Products/Debug/new
 test.app/Contents/MacOS/new test

If bar() is declared as private instead of internal, the library’s copy of bar 
gets called each time, but the crash still happens if I remove the method from 
the framework without recompiling the app.

So, in summary: Swift doesn’t fix the problem Objective-C has, and it adds a 
new one.

> However, the test you did doesn’t give much cause for optimism. I suppose 
> *selectors* would have to be namespaced to solve the problem for the Obj-C 
> runtime, wouldn’t it? For compatibility reasons, that seems unlikely, which 
> makes it unlikely that this problem will ever be solved for Cocoa frameworks.

You could do something like @objc(MyObnoxiousPrefix_foo), and if you were only 
going to call it from Swift anyway, it wouldn’t ugly up your code at all. The 
problem above would still remain, of course (although in all seriousness, I’d 
be kinda surprised if it stayed that way - Swift is clearly still in formative 
stages).

Charles

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Private Methods

[Quincey Morris]

On Aug 18, 2015, at 15:48 , Charles Srstka  wrote:
> 
> Currently, the Swift runtime hasn’t stabilized yet, and it’s pretty unlikely 
> that any system frameworks will be written in it until it is.

The bigger issue, I think, is that apps using Cocoa APIs have to continue to 
run against existing Cocoa frameworks. If this means that Cocoa frameworks 
can’t be modularized/namespaced, then there’ll never be a solution to Richard’s 
“context” problem.

Note that the above statement doesn’t mention language at all. It’s an ABI 
compatibility problem, and I was apparently too naive in hoping that the advent 
of Swift would bring a solution to that problem.

On Aug 18, 2015, at 15:19 , Quincey Morris 
 wrote:
> 
> Actually, I did look, but obviously I did not see.

This is the second time in a week I’ve looked at code and failed to distinguish 
which language it was written in. This is a little worrying. Are we going to 
have to have public service announcements for developers converting to Swift? 
(“This is your brain. This is your brain on Swift.”)



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Private Methods

[Charles Srstka]

> On Aug 18, 2015, at 5:19 PM, Quincey Morris 
>  wrote:
> 
> But, in my own defense, I was looking for verification first that the 
> mechanism is safe in 100% pure Swift. The next thing to verify is whether 
> it’s safe with an @objc base class in Swift. Only if both those things are 
> safe does it make any sense to wonder if an Obj-C base class is safe.
> 
> However, the test you did doesn’t give much cause for optimism. I suppose 
> *selectors* would have to be namespaced to solve the problem for the Obj-C 
> runtime, wouldn’t it? For compatibility reasons, that seems unlikely, which 
> makes it unlikely that this problem will ever be solved for Cocoa frameworks.

Hey, you know what *does* work? Going back to the original test:

MyBaseClass.h:

#import 

@interface MyBaseClass : NSObject

- (void)foo;

@end

MyBaseClass.m (initially):

@implementation MyBaseClass

- (void)foo {
fprintf(stderr, "BOOM!\n");
}

@end

App code:

import MyFramework

class MyClass: MyBaseClass {
@nonobjc func bar() {
print("BLEAH!")
}
}

let obj = MyClass()

obj.foo()

Output:

BOOM!

MyBaseClass.m changed to:

#import "MyBaseClass.h"

@implementation MyBaseClass

- (void)foo {
fprintf(stderr, "BOOM!\n");

[self bar];
}

- (void)bar {
fprintf(stderr, "It actually succeeded at Not Being Seen\n");
}

@end

Output without recompiling:

BOOM!
It actually succeeded at Not Being Seen

Output after recompiling the app:

BOOM!
It actually succeeded at Not Being Seen

And reverting MyBaseClass.m to the original and not recompiling the app:

BOOM!

So, if you declare all your new methods as @nonobjc and the base class remains 
written in Objective-C, any new private method added to the base class will be 
concealed extremely well.

However, we happen to know, it's in the water barrel. (“BOOM!”)

Charles

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Private Methods

[Quincey Morris]

On Aug 18, 2015, at 15:48 , Charles Srstka  wrote:
> 
> If bar() is declared as private instead of internal, the library’s copy of 
> bar gets called each time

The most likely difference resulting from that is that private bar can be 
inferred to be ‘final’, whereas I’m not sure that internal bar gets anything 
inferred (currently) without whole-module optimization turned on.

So maybe the results you're seeing (in the other test, too, perhaps) reflect 
the difference between dynamic dispatch and static call, rather than some other 
(hypothetical) mechanism that keeps method names separate across module 
boundaries.



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Private Methods

[Charles Srstka]

On Aug 18, 2015, at 6:22 PM, Quincey Morris 
 wrote:
> 
> On Aug 18, 2015, at 15:48 , Charles Srstka  > wrote:
>> 
>> If bar() is declared as private instead of internal, the library’s copy of 
>> bar gets called each time
> 
> The most likely difference resulting from that is that private bar can be 
> inferred to be ‘final’, whereas I’m not sure that internal bar gets anything 
> inferred (currently) without whole-module optimization turned on.
> 
> So maybe the results you're seeing (in the other test, too, perhaps) reflect 
> the difference between dynamic dispatch and static call, rather than some 
> other (hypothetical) mechanism that keeps method names separate across module 
> boundaries.

Nope, I think I’ve figured out what was going on, and it’s much simpler than 
either of those things:

Framework code:

public class BaseClass {
public init() {}

public func foo() {
print("Foo called in library")
}
}

App code:

import MyFramework

class DerivedClass: BaseClass {
func bar() {
print("Bar called in app")
}
}

let obj = DerivedClass()

obj.foo()

New framework code:

public class BaseClass {
public init() {}

public func foo() {
print("Foo called in library")

self.definitelyNotBar()
}

internal func definitelyNotBar() {
print("definitelyNotBar called in library")
}
}

Output:

Foo called in library
Bar called in app

Yep, we’ve re-invented the base class problem.

Charles

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Private Methods

[Jens Alfke]

> On Aug 20, 2015, at 4:10 AM, Jeremy Pereira 
>  wrote:
> 
>> The (Obj-C) compiler knows if a superclass declares a method with the same 
>> selector.
> 
> Only if the method is declared in in @interface that has been imported.  It 
> could have been declared in a private category or class extension or even not 
> at all.  

Yes, that’s what I meant. By “declares” I meant “includes in its public 
interface”. Obviously the method could be declared privately or only appear in 
the @implementation. I was just rebutting Maxthon’s assertion that the compiler 
knows “nothing”.

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Private Methods

[Dave]

>> Does anyone prefix their private method names like Apple recommends when 
>> subclassing a large Cocoa framework class?
>> 
>> Also why does Apple say "If you are subclassing a large Cocoa framework 
>> class”. What if I am subclassing a small Cocoa framework class. What 
>> difference would it make?

Usually my Class would have a name like LTWConfigValidation, so for private 
methods I tend to call internal methods something like:

validationFindNextItem:

If I don’t prefix the name, then I’d make it more verbose:

findNextItemInArray or whatever.

Also, I prefix properties with “p” and instance variables with “m”. 

This minimises to almost nothing the chance of getting conflicts.

Cheers
Dave


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Private Methods

[Mike Abdullah]

It's not possible to do this. ObjC will allow you to send any message  
to any other object. The best you can do is not publicly expose the  
method and that is exactly what the Cocoa framework does. To be  
honest, trying to use C++ just for this seems a waste of time; perhaps  
you should explain why you want to do this? Is it to try and partition  
your code up, is this something that really MUST stop, say, plugins  
from accessing the code?


Mike.

On 22 Feb 2008, at 11:00, Philip Bridson wrote:


How do I make a method private?

I have tried putting @private before the method that I want to make  
private but the compiler flags a parse error. I read the  
documentation and I can only find reference to private member  
variables. I want to make sure that a method can only be accessed  
via another method in the same class. Is this possible in Objective- 
C or do I need to write this class in C++?


Many thanks.

Phil.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/cocoadev%40mikeabdullah.net

This email sent to [EMAIL PROTECTED]


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Private Methods

[Jean-Daniel Dupas]

Le 22 févr. 08 à 12:00, Philip Bridson a écrit :


How do I make a method private?

I have tried putting @private before the method that I want to make  
private but the compiler flags a parse error. I read the  
documentation and I can only find reference to private member  
variables. I want to make sure that a method can only be accessed  
via another method in the same class. Is this possible in Objective- 
C or do I need to write this class in C++?


Many thanks.

Phil.



If you realy want to call this method only from your class, you can  
convert it into a function (instead of using C++).
As long as this function stay in the class implementation (between  
@implementation and @end) you can access private variable using the  
self->_ivar syntaxt.


- (void)myPrivateMethod:(id)arg {
/* do whatever you want */
}

static void myPrivateFunction(MyClass *self, id arg) {
/* do whatever you want */
}___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Private Methods

[Rob Petrovec]

Lack of private methods is a serious flaw in Obj-C IMO.  There are  
just as many reasons why someone would want to make a variable private  
as they would want to make a method private.  For example if your  
writing a class that is part of a library that other developers will  
be using (quite common in large projects).  You may want to hide  
implementation details from them, or prevent them from calling a  
method that requires another to be called before/after it in order to  
work properly etc (in other words, prevent them from shooting  
themselves in the foot by calling methods they shouldn't be).  Being  
able to do this type of thing is one of the more powerful/useful  
features of C++ IMO.


--Rob


On Feb 22, 2008, at 3:24 AM, Mike Abdullah wrote:

It's not possible to do this. ObjC will allow you to send any  
message to any other object. The best you can do is not publicly  
expose the method and that is exactly what the Cocoa framework does.  
To be honest, trying to use C++ just for this seems a waste of time;  
perhaps you should explain why you want to do this? Is it to try and  
partition your code up, is this something that really MUST stop,  
say, plugins from accessing the code?


Mike.

On 22 Feb 2008, at 11:00, Philip Bridson wrote:


How do I make a method private?

I have tried putting @private before the method that I want to make  
private but the compiler flags a parse error. I read the  
documentation and I can only find reference to private member  
variables. I want to make sure that a method can only be accessed  
via another method in the same class. Is this possible in Objective- 
C or do I need to write this class in C++?


Many thanks.

Phil.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/cocoadev%40mikeabdullah.net

This email sent to [EMAIL PROTECTED]


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com

This email sent to [EMAIL PROTECTED]


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Private Methods

[matt . gough]

On 22 Feb 2008, at 12:00, Philip Bridson wrote:


How do I make a method private?

I have tried putting @private before the method that I want to make  
private but the compiler flags a parse error. I read the  
documentation and I can only find reference to private member  
variables. I want to make sure that a method can only be accessed  
via another method in the same class. Is this possible in Objective- 
C or do I need to write this class in C++?




No, you can't declare methods private in an interface.

What you can do, in your .m file is declare a private interface to  
your object.


E.g in MyObj.h

@interface MyObj : NSObject {

}

-(void) onePublicMethod;

@end

In MyObj.m

@interface MyObj(PrivateStuff)
-(void) aPrivateMethod;
@end;

@implementation MyObj

-(void) aPrivateMethod
{
// Do something
}

-(void) onePublicMethod
{
[self aPrivateMethod];
}
@end


As with all Obj-C stuff though, if someone finds out about your method  
signature, then there is nothing to stop them calling it.


Matt
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Private Methods

[Philip Bridson]

I agree.

Your point hit the nail on the head and is exactly the reason that I  
do not want this method to be public. If it is called externally it  
will cause an error. Even if I put the 'private' method into the .m  
file it can still be found by using the pop up list of methods  
available. Although, why some one would want to try to do something  
they are not supposed to is a mystery, but that does not mean that  
someone won't try.


Thank you all for your help.

Phil.

On 22 Feb 2008, at 11:48, Rob Petrovec wrote:

Lack of private methods is a serious flaw in Obj-C IMO.  There are  
just as many reasons why someone would want to make a variable  
private as they would want to make a method private.  For example  
if your writing a class that is part of a library that other  
developers will be using (quite common in large projects).  You may  
want to hide implementation details from them, or prevent them from  
calling a method that requires another to be called before/after it  
in order to work properly etc (in other words, prevent them from  
shooting themselves in the foot by calling methods they shouldn't  
be).  Being able to do this type of thing is one of the more  
powerful/useful features of C++ IMO.


--Rob


On Feb 22, 2008, at 3:24 AM, Mike Abdullah wrote:

It's not possible to do this. ObjC will allow you to send any  
message to any other object. The best you can do is not publicly  
expose the method and that is exactly what the Cocoa framework  
does. To be honest, trying to use C++ just for this seems a waste  
of time; perhaps you should explain why you want to do this? Is it  
to try and partition your code up, is this something that really  
MUST stop, say, plugins from accessing the code?


Mike.

On 22 Feb 2008, at 11:00, Philip Bridson wrote:


How do I make a method private?

I have tried putting @private before the method that I want to  
make private but the compiler flags a parse error. I read the  
documentation and I can only find reference to private member  
variables. I want to make sure that a method can only be accessed  
via another method in the same class. Is this possible in  
Objective-C or do I need to write this class in C++?


Many thanks.

Phil.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/cocoadev% 
40mikeabdullah.net


This email sent to [EMAIL PROTECTED]


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com

This email sent to [EMAIL PROTECTED]




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Private Methods

[Jean-Daniel Dupas]

This is an old Eiffel vs SmallTalk discussion. Should errors occured  
at compile time or at runtime?


Anyway, I do not understand what prevent you to hide implementation  
details to other developers?
As other state, if you do not declare your method in an exported  
header, how do other developers will use them?



Le 22 févr. 08 à 12:48, Rob Petrovec a écrit :

Lack of private methods is a serious flaw in Obj-C IMO.  There are  
just as many reasons why someone would want to make a variable  
private as they would want to make a method private.  For example if  
your writing a class that is part of a library that other developers  
will be using (quite common in large projects).  You may want to  
hide implementation details from them, or prevent them from calling  
a method that requires another to be called before/after it in order  
to work properly etc (in other words, prevent them from shooting  
themselves in the foot by calling methods they shouldn't be).  Being  
able to do this type of thing is one of the more powerful/useful  
features of C++ IMO.


--Rob


On Feb 22, 2008, at 3:24 AM, Mike Abdullah wrote:

It's not possible to do this. ObjC will allow you to send any  
message to any other object. The best you can do is not publicly  
expose the method and that is exactly what the Cocoa framework  
does. To be honest, trying to use C++ just for this seems a waste  
of time; perhaps you should explain why you want to do this? Is it  
to try and partition your code up, is this something that really  
MUST stop, say, plugins from accessing the code?


Mike.

On 22 Feb 2008, at 11:00, Philip Bridson wrote:


How do I make a method private?

I have tried putting @private before the method that I want to  
make private but the compiler flags a parse error. I read the  
documentation and I can only find reference to private member  
variables. I want to make sure that a method can only be accessed  
via another method in the same class. Is this possible in  
Objective-C or do I need to write this class in C++?


Many thanks.

Phil.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/cocoadev%40mikeabdullah.net

This email sent to [EMAIL PROTECTED]


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com

This email sent to [EMAIL PROTECTED]


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/devlists%40shadowlab.org

This email sent to [EMAIL PROTECTED]



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Private Methods

[Philip Bridson]

Just to finish the discussion, but I have also just found out that  
you cannot overload functions in Objective-C to accept different  
arguments. I feel this is also an important feature that needs to be  
addressed.


Phil.

On 22 Feb 2008, at 12:16, Philip Bridson wrote:


I agree.

Your point hit the nail on the head and is exactly the reason that  
I do not want this method to be public. If it is called externally  
it will cause an error. Even if I put the 'private' method into  
the .m file it can still be found by using the pop up list of  
methods available. Although, why some one would want to try to do  
something they are not supposed to is a mystery, but that does not  
mean that someone won't try.


Thank you all for your help.

Phil.

On 22 Feb 2008, at 11:48, Rob Petrovec wrote:

Lack of private methods is a serious flaw in Obj-C IMO.  There are  
just as many reasons why someone would want to make a variable  
private as they would want to make a method private.  For example  
if your writing a class that is part of a library that other  
developers will be using (quite common in large projects).  You  
may want to hide implementation details from them, or prevent them  
from calling a method that requires another to be called before/ 
after it in order to work properly etc (in other words, prevent  
them from shooting themselves in the foot by calling methods they  
shouldn't be).  Being able to do this type of thing is one of the  
more powerful/useful features of C++ IMO.


--Rob


On Feb 22, 2008, at 3:24 AM, Mike Abdullah wrote:

It's not possible to do this. ObjC will allow you to send any  
message to any other object. The best you can do is not publicly  
expose the method and that is exactly what the Cocoa framework  
does. To be honest, trying to use C++ just for this seems a waste  
of time; perhaps you should explain why you want to do this? Is  
it to try and partition your code up, is this something that  
really MUST stop, say, plugins from accessing the code?


Mike.

On 22 Feb 2008, at 11:00, Philip Bridson wrote:


How do I make a method private?

I have tried putting @private before the method that I want to  
make private but the compiler flags a parse error. I read the  
documentation and I can only find reference to private member  
variables. I want to make sure that a method can only be  
accessed via another method in the same class. Is this possible  
in Objective-C or do I need to write this class in C++?


Many thanks.

Phil.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the  
list.

Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/cocoadev% 
40mikeabdullah.net


This email sent to [EMAIL PROTECTED]


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com

This email sent to [EMAIL PROTECTED]




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/philipleebridson% 
40mac.com


This email sent to [EMAIL PROTECTED]


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Private Methods

[João Pavão]

I don't agree at all. :)

Whatever you declare in the header file of your class will be the  
public API that establishes the "contract" between you and the users  
of your code. "If you use my class this way, it will behave correctly  
and do this and that stuff for you". It's in the best interest of the  
users of your code to not shoot themselves in the foot, so they're  
likely to follow good practices and avoid poking around your private  
stuff so that their stuff works flawlessly, and remains so even after  
they perform an update of your classes to a more recent version.


What do you gain by deciding (and forcing) what a user of the code can  
and cannot do with it?

--
João Pavão



On 2008/02/22, at 12:16, Philip Bridson wrote:


I agree.

Your point hit the nail on the head and is exactly the reason that I  
do not want this method to be public. If it is called externally it  
will cause an error. Even if I put the 'private' method into the .m  
file it can still be found by using the pop up list of methods  
available. Although, why some one would want to try to do something  
they are not supposed to is a mystery, but that does not mean that  
someone won't try.


Thank you all for your help.

Phil.

On 22 Feb 2008, at 11:48, Rob Petrovec wrote:

Lack of private methods is a serious flaw in Obj-C IMO.  There are  
just as many reasons why someone would want to make a variable  
private as they would want to make a method private.  For example  
if your writing a class that is part of a library that other  
developers will be using (quite common in large projects).  You may  
want to hide implementation details from them, or prevent them from  
calling a method that requires another to be called before/after it  
in order to work properly etc (in other words, prevent them from  
shooting themselves in the foot by calling methods they shouldn't  
be).  Being able to do this type of thing is one of the more  
powerful/useful features of C++ IMO.


--Rob


On Feb 22, 2008, at 3:24 AM, Mike Abdullah wrote:

It's not possible to do this. ObjC will allow you to send any  
message to any other object. The best you can do is not publicly  
expose the method and that is exactly what the Cocoa framework  
does. To be honest, trying to use C++ just for this seems a waste  
of time; perhaps you should explain why you want to do this? Is it  
to try and partition your code up, is this something that really  
MUST stop, say, plugins from accessing the code?


Mike.

On 22 Feb 2008, at 11:00, Philip Bridson wrote:


How do I make a method private?

I have tried putting @private before the method that I want to  
make private but the compiler flags a parse error. I read the  
documentation and I can only find reference to private member  
variables. I want to make sure that a method can only be accessed  
via another method in the same class. Is this possible in  
Objective-C or do I need to write this class in C++?


Many thanks.

Phil.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the  
list.

Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/cocoadev%40mikeabdullah.net

This email sent to [EMAIL PROTECTED]


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com

This email sent to [EMAIL PROTECTED]




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/jpavao-lists%40sericaia.com

This email sent to [EMAIL PROTECTED]


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Private Methods

[João Pavão]

Also disagree on that one. :)

Function/method overloading based on the static types of the arguments  
is just a compile-time feature that adds no value whatsoever, probably  
only adds a bit of confusion for the programmer.  
The ...WithX:, ...WithY: methods look fine to me! Much more  
descriptive and self documenting.

--
João Pavão

PS: Maybe I got too influenced by the opinions of one of my LISP  
adoring professors from college. :)



On 2008/02/22, at 12:38, Philip Bridson wrote:

Just to finish the discussion, but I have also just found out that  
you cannot overload functions in Objective-C to accept different  
arguments. I feel this is also an important feature that needs to be  
addressed.


Phil.

On 22 Feb 2008, at 12:16, Philip Bridson wrote:


I agree.

Your point hit the nail on the head and is exactly the reason that  
I do not want this method to be public. If it is called externally  
it will cause an error. Even if I put the 'private' method into  
the .m file it can still be found by using the pop up list of  
methods available. Although, why some one would want to try to do  
something they are not supposed to is a mystery, but that does not  
mean that someone won't try.


Thank you all for your help.

Phil.

On 22 Feb 2008, at 11:48, Rob Petrovec wrote:

Lack of private methods is a serious flaw in Obj-C IMO.  There are  
just as many reasons why someone would want to make a variable  
private as they would want to make a method private.  For example  
if your writing a class that is part of a library that other  
developers will be using (quite common in large projects).  You  
may want to hide implementation details from them, or prevent them  
from calling a method that requires another to be called before/ 
after it in order to work properly etc (in other words, prevent  
them from shooting themselves in the foot by calling methods they  
shouldn't be).  Being able to do this type of thing is one of the  
more powerful/useful features of C++ IMO.


--Rob


On Feb 22, 2008, at 3:24 AM, Mike Abdullah wrote:

It's not possible to do this. ObjC will allow you to send any  
message to any other object. The best you can do is not publicly  
expose the method and that is exactly what the Cocoa framework  
does. To be honest, trying to use C++ just for this seems a waste  
of time; perhaps you should explain why you want to do this? Is  
it to try and partition your code up, is this something that  
really MUST stop, say, plugins from accessing the code?


Mike.

On 22 Feb 2008, at 11:00, Philip Bridson wrote:


How do I make a method private?

I have tried putting @private before the method that I want to  
make private but the compiler flags a parse error. I read the  
documentation and I can only find reference to private member  
variables. I want to make sure that a method can only be  
accessed via another method in the same class. Is this possible  
in Objective-C or do I need to write this class in C++?


Many thanks.

Phil.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the  
list.

Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/cocoadev%40mikeabdullah.net

This email sent to [EMAIL PROTECTED]


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the  
list.

Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com

This email sent to [EMAIL PROTECTED]




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/philipleebridson%40mac.com

This email sent to [EMAIL PROTECTED]


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/jpavao-lists%40sericaia.com

This email sent to [EMAIL PROTECTED]


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Private Methods

[Philip Bridson]

What do you gain by deciding (and forcing) what a user of the code  
can and cannot do with it?


Is that not the whole reason that @public, @protected and @private  
are used? To limit what the user has access to?


We write classes that provide a certain functionality to the user of  
our class. We define what a user can and cannot do with our class. I  
agree that it is in the best interest of the users not to poke around  
in our private methods but accidents happen unfortunately and isn't  
it our job as a developer to protect against such events? Isn't half  
the code we write put there to fix errors, bugs or to prevent  
possible errors? We, as developers, should not develop code that has  
a known error and submit it on the basis that we trust the end user  
will have the sense not to call the wrong function. Accidents happen.


Phil.

On 22 Feb 2008, at 12:41, João Pavão wrote:


I don't agree at all. :)

Whatever you declare in the header file of your class will be the  
public API that establishes the "contract" between you and the  
users of your code. "If you use my class this way, it will behave  
correctly and do this and that stuff for you". It's in the best  
interest of the users of your code to not shoot themselves in the  
foot, so they're likely to follow good practices and avoid poking  
around your private stuff so that their stuff works flawlessly, and  
remains so even after they perform an update of your classes to a  
more recent version.


What do you gain by deciding (and forcing) what a user of the code  
can and cannot do with it?

--
João Pavão



On 2008/02/22, at 12:16, Philip Bridson wrote:


I agree.

Your point hit the nail on the head and is exactly the reason that  
I do not want this method to be public. If it is called externally  
it will cause an error. Even if I put the 'private' method into  
the .m file it can still be found by using the pop up list of  
methods available. Although, why some one would want to try to do  
something they are not supposed to is a mystery, but that does not  
mean that someone won't try.


Thank you all for your help.

Phil.

On 22 Feb 2008, at 11:48, Rob Petrovec wrote:

Lack of private methods is a serious flaw in Obj-C IMO.  There  
are just as many reasons why someone would want to make a  
variable private as they would want to make a method private.   
For example if your writing a class that is part of a library  
that other developers will be using (quite common in large  
projects).  You may want to hide implementation details from  
them, or prevent them from calling a method that requires another  
to be called before/after it in order to work properly etc (in  
other words, prevent them from shooting themselves in the foot by  
calling methods they shouldn't be).  Being able to do this type  
of thing is one of the more powerful/useful features of C++ IMO.


--Rob


On Feb 22, 2008, at 3:24 AM, Mike Abdullah wrote:

It's not possible to do this. ObjC will allow you to send any  
message to any other object. The best you can do is not publicly  
expose the method and that is exactly what the Cocoa framework  
does. To be honest, trying to use C++ just for this seems a  
waste of time; perhaps you should explain why you want to do  
this? Is it to try and partition your code up, is this something  
that really MUST stop, say, plugins from accessing the code?


Mike.

On 22 Feb 2008, at 11:00, Philip Bridson wrote:


How do I make a method private?

I have tried putting @private before the method that I want to  
make private but the compiler flags a parse error. I read the  
documentation and I can only find reference to private member  
variables. I want to make sure that a method can only be  
accessed via another method in the same class. Is this possible  
in Objective-C or do I need to write this class in C++?


Many thanks.

Phil.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the  
list.

Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/cocoadev% 
40mikeabdullah.net


This email sent to [EMAIL PROTECTED]


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the  
list.

Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com

This email sent to [EMAIL PROTECTED]




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubs

Re: Private Methods

[Jean-Daniel Dupas]

Le 22 févr. 08 à 14:04, Philip Bridson a écrit :

What do you gain by deciding (and forcing) what a user of the code  
can and cannot do with it?


Is that not the whole reason that @public, @protected and @private  
are used? To limit what the user has access to?


We write classes that provide a certain functionality to the user of  
our class. We define what a user can and cannot do with our class. I  
agree that it is in the best interest of the users not to poke  
around in our private methods but accidents happen unfortunately and  
isn't it our job as a developer to protect against such events?  
Isn't half the code we write put there to fix errors, bugs or to  
prevent possible errors? We, as developers, should not develop code  
that has a known error and submit it on the basis that we trust the  
end user will have the sense not to call the wrong function.  
Accidents happen.


Phil.

On 22 Feb 2008, at 12:41, João Pavão wrote:



ivar MUST be declared in the public header, so you need a way to  
restrict access. This is not the case for methods. Declaring a method  
in the .m file mean this is a private method and used of your class  
will never see the method declaration.


Give a place where the lack of private method is a problem in the  
Cocoa framework for example.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Private Methods

[Adam P Jenkins]

On Feb 22, 2008, at 6:48 AM, Rob Petrovec wrote:


Lack of private methods is a serious flaw in Obj-C IMO.


This is silly.  Private is really just about as voluntary in C++ as it  
is in ObjC.  If a user of your class wants to ignore your decisions  
about what should be private methods, they have only to write:


#define private public
#include "yourclass.h"
#undef private

void foo() {
  YourClass obj;
  obj.aPrivateMethod();  // no compiler errors or warnings
}

So declaring things private in C++ is just an advisory to users of  
your class that certain methods and fields aren't intended to be used  
by clients of the class, it's not meant as any kind of security  
mechanism.  In ObjC you can achieve the same thing by not declaring  
methods in the interface file, so if a user of your class still finds  
out about the method somehow and calls it, they'll get a compiler  
warning and will know they're doing something not intended by the  
class's author.


Note that this is in contrast to Java or C#, which run in managed  
environments, and where private really can be used to fairly securely  
block certain methods and fields from being accessed, when using the  
correct security settings in the VM.


That said I do agree that it's nicer to have a formal language  
construct for specifying what's private, like in C++, than the ad-hoc  
mechanisms available in ObjC.  I just don't agree that it's really a  
serious flaw, more of a minor flaw. 
 
___


Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Private Methods

[Adhamh Findlay]

On Feb 22, 2008, at 5:23 AM, [EMAIL PROTECTED] wrote:


In MyObj.m

@interface MyObj(PrivateStuff)
-(void) aPrivateMethod;
@end;

@implementation MyObj

-(void) aPrivateMethod
{
// Do something
}

-(void) onePublicMethod
{
[self aPrivateMethod];
}
@end


Not to be too picky, but there's an extra semicolon after @end;

@interface MyObj(PrivateStuff)
-(void) aPrivateMethod;
@end

Adhamh
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Private Methods

[Jean-Daniel Dupas]

Le 22 févr. 08 à 15:57, Adhamh Findlay a écrit :



On Feb 22, 2008, at 5:23 AM, [EMAIL PROTECTED] wrote:


In MyObj.m

@interface MyObj(PrivateStuff)
-(void) aPrivateMethod;
@end;

@implementation MyObj

-(void) aPrivateMethod
{
// Do something
}

-(void) onePublicMethod
{
[self aPrivateMethod];
}
@end


Not to be too picky, but there's an extra semicolon after @end;

@interface MyObj(PrivateStuff)
-(void) aPrivateMethod;
@end

Adhamh


If you want to be picky, I will also add that using a class extension  
will be more appropriate, so the compiler will emit a warning if you  
do not implements the private methods:


@interface MyObj ()
-(void) aPrivateMethod;
@end


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Private Methods

[Corbin Dunn]

Please do log this as a bug/feature request for obj-c. (To make  
@private, etc work on methods).


-corbin

On Feb 22, 2008, at 3:00 AM, Philip Bridson wrote:


How do I make a method private?


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Private Methods

[Jonathan Hess]

On Feb 22, 2008, at 6:08 AM, Adam P Jenkins wrote:


On Feb 22, 2008, at 6:48 AM, Rob Petrovec wrote:


Lack of private methods is a serious flaw in Obj-C IMO.


This is silly.  Private is really just about as voluntary in C++ as  
it is in ObjC.  If a user of your class wants to ignore your  
decisions about what should be private methods, they have only to  
write:


#define private public
#include "yourclass.h"
#undef private

void foo() {
 YourClass obj;
 obj.aPrivateMethod();  // no compiler errors or warnings
}

So declaring things private in C++ is just an advisory to users of  
your class that certain methods and fields aren't intended to be  
used by clients of the class, it's not meant as any kind of security  
mechanism.  In ObjC you can achieve the same thing by not declaring  
methods in the interface file, so if a user of your class still  
finds out about the method somehow and calls it, they'll get a  
compiler warning and will know they're doing something not intended  
by the class's author.


Note that this is in contrast to Java or C#, which run in managed  
environments, and where private really can be used to fairly  
securely block certain methods and fields from being accessed, when  
using the correct security settings in the VM.


That said I do agree that it's nicer to have a formal language  
construct for specifying what's private, like in C++, than the ad- 
hoc mechanisms available in ObjC.  I just don't agree that it's  
really a serious flaw, more of a minor  
flaw.___


If a method is private, why would you ever want to place it in a  
public header? I could see a justification for @proected applying to  
methods, but it seems much better to just not have the private methods  
in the interface at all. Putting a private method in the interface  
says "This exists, and you can't use it." If I can't use it, why are  
you telling me it is there?


I believe that in c++ the MyClass.h file is the *only* interface to  
your class. In objective-c, the MyClass.h file is simply the public  
interface to your class. You're free to have more than one @interface  
and you are encouraged to use them to declare things that shouldn't be  
part of your outward facing public interface.


Things would be best if we didn't even have to put our private  
instance variables in the header -

Jon Hess




Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/jhess%40apple.com

This email sent to [EMAIL PROTECTED]


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Private Methods

[Adam P Jenkins]

On Feb 23, 2008, at 5:15 PM, Jonathan Hess wrote:



On Feb 22, 2008, at 6:08 AM, Adam P Jenkins wrote:


On Feb 22, 2008, at 6:48 AM, Rob Petrovec wrote:


Lack of private methods is a serious flaw in Obj-C IMO.


This is silly.  Private is really just about as voluntary in C++ as  
it is in ObjC.  If a user of your class wants to ignore your  
decisions about what should be private methods, they have only to  
write:


#define private public
#include "yourclass.h"
#undef private

void foo() {
YourClass obj;
obj.aPrivateMethod();  // no compiler errors or warnings
}

So declaring things private in C++ is just an advisory to users of  
your class that certain methods and fields aren't intended to be  
used by clients of the class, it's not meant as any kind of  
security mechanism.  In ObjC you can achieve the same thing by not  
declaring methods in the interface file, so if a user of your class  
still finds out about the method somehow and calls it, they'll get  
a compiler warning and will know they're doing something not  
intended by the class's author.


Note that this is in contrast to Java or C#, which run in managed  
environments, and where private really can be used to fairly  
securely block certain methods and fields from being accessed, when  
using the correct security settings in the VM.


That said I do agree that it's nicer to have a formal language  
construct for specifying what's private, like in C++, than the ad- 
hoc mechanisms available in ObjC.  I just don't agree that it's  
really a serious flaw, more of a minor  
flaw.___


If a method is private, why would you ever want to place it in a  
public header? I could see a justification for @proected applying to  
methods, but it seems much better to just not have the private  
methods in the interface at all. Putting a private method in the  
interface says "This exists, and you can't use it." If I can't use  
it, why are you telling me it is there?


I believe that in c++ the MyClass.h file is the *only* interface to  
your class. In objective-c, the MyClass.h file is simply the public  
interface to your class. You're free to have more than one  
@interface and you are encouraged to use them to declare things that  
shouldn't be part of your outward facing public interface.


Things would be best if we didn't even have to put our private  
instance variables in the header -

Jon Hess


I agree that this is a way in which ObjC is actually better about  
separating public from private than C++, that you don't need to add  
private methods to the public header file at all, though the same  
problem still exists for instance variables, at least with the 32 bit  
runtime.  You can get the same effect in C++ though by using the Pimpl  
idiom: http://c2.com/cgi/wiki?PimplIdiom .


Adam


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Subclassing and private methods

[Rick Aurbach]

I am using a CocoaPod that ALMOST does what I want it to. It appears that I can 
get the desired behaviors by subclassing it (creating a category is also a 
possibility, although doing so has the same problems as subclassing).

Obviously, I would like to create as minimal a subclass as possible (and 
avoiding duplicating existing code), but doing so requires access to private 
methods of the original object. The problem is that I need to use methods which 
are not declared outside of the @implementation section of the class and a 
property which is ONLY declared in the class’s anonymous category interface 
(i.e., @interface theClass ()  … @end)..

Now I understand that trying to gain access to private methods is generally a 
BAD IDEA, since almost any change to the original CocoaPod could break my 
class. And I may (i.e., probably will) resolve the issue by duplicating 
otherwise unnecessary code in my subclass. But before I do so, I’d like to 
survey what people think, how they approach this problem, etc.

(This is sort of like the undefined selector issue that has been discussed 
recently, but seems to me to be a slightly different wrinkle.)

What do you do??

Cheers,

Rick Aurbach
Aurbach & Associates, Inc.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

private methods and variables

[Torsten Curdt]

This question is NOT about private APIs from Apple but more about how  
to organize structure my own code.


Especially for a framework I don't want to expose implementation  
details to the interface.

So while I found the suggestion to use a special category like:

 @interface MyClass
 -(void) publicMethod;
 @end

 @interface MyClass (Private)
 {
int privateVariable;
 }
 -(void) privateMethod;
 @end

I am not sure why that would be better than to just do

 @interface MyClass
 -(void) publicMethod;
 @end

 @implementation MyClass

 int privateVariable;
 -(void) privateMethod {
 }

 -(void) publicMethod {
 }

 @end

Any wise words?

cheers
--
Torsten
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Subclassing and private methods

[Charles Srstka]

On May 7, 2014, at 2:24 PM, Rick Aurbach  wrote:

> I am using a CocoaPod that ALMOST does what I want it to. It appears that I 
> can get the desired behaviors by subclassing it (creating a category is also 
> a possibility, although doing so has the same problems as subclassing).
> 
> Obviously, I would like to create as minimal a subclass as possible (and 
> avoiding duplicating existing code), but doing so requires access to private 
> methods of the original object. The problem is that I need to use methods 
> which are not declared outside of the @implementation section of the class 
> and a property which is ONLY declared in the class’s anonymous category 
> interface (i.e., @interface theClass ()  … @end)..
> 
> Now I understand that trying to gain access to private methods is generally a 
> BAD IDEA, since almost any change to the original CocoaPod could break my 
> class. And I may (i.e., probably will) resolve the issue by duplicating 
> otherwise unnecessary code in my subclass. But before I do so, I’d like to 
> survey what people think, how they approach this problem, etc.
> 
> (This is sort of like the undefined selector issue that has been discussed 
> recently, but seems to me to be a slightly different wrinkle.)
> 
> What do you do??

Is the superclass your code? If it is, just move the class extension (i.e. 
@interface MyClass () ... @end) to a separate file named MyClassPrivate.h, add 
declarations for any private methods the subclass needs to call, and have the 
subclass import that.

If the superclass is not your code, then it's best to find a way to do what you 
need without calling the private methods.

Charles


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Subclassing and private methods

[Rick Aurbach]

On May 7, 2014, at 2:33 PM, Charles Srstka  wrote:

> On May 7, 2014, at 2:24 PM, Rick Aurbach  wrote:
> 
>> I am using a CocoaPod that ALMOST does what I want it to. It appears that I 
>> can get the desired behaviors by subclassing it (creating a category is also 
>> a possibility, although doing so has the same problems as subclassing).
>> 
>> Obviously, I would like to create as minimal a subclass as possible (and 
>> avoiding duplicating existing code), but doing so requires access to private 
>> methods of the original object. The problem is that I need to use methods 
>> which are not declared outside of the @implementation section of the class 
>> and a property which is ONLY declared in the class’s anonymous category 
>> interface (i.e., @interface theClass ()  … @end)..
>> 
>> Now I understand that trying to gain access to private methods is generally 
>> a BAD IDEA, since almost any change to the original CocoaPod could break my 
>> class. And I may (i.e., probably will) resolve the issue by duplicating 
>> otherwise unnecessary code in my subclass. But before I do so, I’d like to 
>> survey what people think, how they approach this problem, etc.
>> 
>> (This is sort of like the undefined selector issue that has been discussed 
>> recently, but seems to me to be a slightly different wrinkle.)
>> 
>> What do you do??
> 
> Is the superclass your code? If it is, just move the class extension (i.e. 
> @interface MyClass () ... @end) to a separate file named MyClassPrivate.h, 
> add declarations for any private methods the subclass needs to call, and have 
> the subclass import that.
> 
> If the superclass is not your code, then it's best to find a way to do what 
> you need without calling the private methods.

Thank you Charles. I agree with both of your thoughts. (I.e., I had considered 
the private interface file and your second point is exactly why I pointed out 
that it was probably a bad idea…

You help confirm my own thinking on this.

Cheers,

Rick Aurbach
Aurbach & Associates, Inc.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Subclassing and private methods

[Michelangelo Chasseur]

I would also consider forking the original project and modifying the pod. Then 
you would be able to include the pod in you Podfile by just specifying the URL 
of the forked git repo.

Just my 2 cents.

Mike  

--  
Michelangelo Chasseur


Il giorno mercoledì 7 maggio 2014, alle ore 21:38, Rick Aurbach ha scritto:  

> On May 7, 2014, at 2:33 PM, Charles Srstka  (mailto:cocoa...@charlessoft.com)> wrote:
>  
> > On May 7, 2014, at 2:24 PM, Rick Aurbach  > (mailto:r...@aurbach.com)> wrote:
> >  
> > > I am using a CocoaPod that ALMOST does what I want it to. It appears that 
> > > I can get the desired behaviors by subclassing it (creating a category is 
> > > also a possibility, although doing so has the same problems as 
> > > subclassing).
> > >  
> > > Obviously, I would like to create as minimal a subclass as possible (and 
> > > avoiding duplicating existing code), but doing so requires access to 
> > > private methods of the original object. The problem is that I need to use 
> > > methods which are not declared outside of the @implementation section of 
> > > the class and a property which is ONLY declared in the class’s anonymous 
> > > category interface (i.e., @interface theClass () … @end)..
> > >  
> > > Now I understand that trying to gain access to private methods is 
> > > generally a BAD IDEA, since almost any change to the original CocoaPod 
> > > could break my class. And I may (i.e., probably will) resolve the issue 
> > > by duplicating otherwise unnecessary code in my subclass. But before I do 
> > > so, I’d like to survey what people think, how they approach this problem, 
> > > etc.
> > >  
> > > (This is sort of like the undefined selector issue that has been 
> > > discussed recently, but seems to me to be a slightly different wrinkle.)
> > >  
> > > What do you do??
> >  
> > Is the superclass your code? If it is, just move the class extension (i.e. 
> > @interface MyClass () ... @end) to a separate file named MyClassPrivate.h, 
> > add declarations for any private methods the subclass needs to call, and 
> > have the subclass import that.
> >  
> > If the superclass is not your code, then it's best to find a way to do what 
> > you need without calling the private methods.
>  
> Thank you Charles. I agree with both of your thoughts. (I.e., I had 
> considered the private interface file and your second point is exactly why I 
> pointed out that it was probably a bad idea…
>  
> You help confirm my own thinking on this.
>  
> Cheers,
>  
> Rick Aurbach
> Aurbach & Associates, Inc.
>  
>  
> ___
>  
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com 
> (mailto:Cocoa-dev@lists.apple.com))
>  
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com 
> (http://lists.apple.com)
>  
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/chasseurmic%40gmail.com
>  
> This email sent to chasseur...@gmail.com (mailto:chasseur...@gmail.com)  

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: private methods and variables

[Bill Bumgarner]

On Jul 29, 2008, at 2:02 PM, Torsten Curdt wrote:

@interface MyClass
-(void) publicMethod;
@end

@interface MyClass (Private)
{
int privateVariable;
}
-(void) privateMethod;
@end

I am not sure why that would be better than to just do

@interface MyClass
-(void) publicMethod;
@end

@implementation MyClass

int privateVariable;
-(void) privateMethod {
}

-(void) publicMethod {
}

@end

Any wise words?


privateVariable is a global in your second example.

b.bum



smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: private methods and variables

[Ken Thomases]

On Jul 29, 2008, at 4:02 PM, Torsten Curdt wrote:

This question is NOT about private APIs from Apple but more about  
how to organize structure my own code.


Especially for a framework I don't want to expose implementation  
details to the interface.

So while I found the suggestion to use a special category like:

@interface MyClass
-(void) publicMethod;
@end

@interface MyClass (Private)
{
int privateVariable;


This is an instance variable.  There's one per instance.




}
-(void) privateMethod;
@end

I am not sure why that would be better than to just do

@interface MyClass
-(void) publicMethod;
@end

@implementation MyClass

int privateVariable;


There is only one of these across the entire program.  It's not an  
instance variable.  It's as close as Objective-C gets to what would be  
a "class variable" in another language.  (Although it should probably  
be declared "static" to limit its linkage to this translation unit.)




-(void) privateMethod {
}

-(void) publicMethod {
}

@end


Cheers,
Ken

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: private methods and variables

[Torsten Curdt]

@implementation MyClass

int privateVariable;


There is only one of these across the entire program.  It's not an  
instance variable.  It's as close as Objective-C gets to what would  
be a "class variable" in another language.  (Although it should  
probably be declared "static" to limit its linkage to this  
translation unit.)




-(void) privateMethod {
}

-(void) publicMethod {
}

@end


Thanks guys. I basically though that there was a difference between:

@implementation MyClass
 int privateVariable;
@end

and

 int privateVariable;
@implementation MyClass
@end

the first being being an ivar. The second just being a global.
But IIUC now - there really is no difference. That correct?

cheers
--
Torsten
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: private methods and variables

[Kyle Sluder]

On Tue, Jul 29, 2008 at 7:30 PM, Torsten Curdt <[EMAIL PROTECTED]> wrote:
> @implementation MyClass
>  int privateVariable;
> @end
>
> and
>
>  int privateVariable;
> @implementation MyClass
> @end
>
> the first being being an ivar. The second just being a global.
> But IIUC now - there really is no difference. That correct?

Did you intend for the first example's ivar to be contained within
braces?  In that case, you were right the first time.

--Kyle Sluder
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: private methods and variables

[Ken Thomases]

On Jul 29, 2008, at 6:30 PM, Torsten Curdt wrote:


Thanks guys. I basically though that there was a difference between:

@implementation MyClass
int privateVariable;
@end

and

int privateVariable;
@implementation MyClass
@end

the first being being an ivar. The second just being a global.
But IIUC now - there really is no difference. That correct?


Correct.

On a somewhat-related subject, there _is_ a difference between:

@implementation MyClass
void someFunction(/* ... */)
{
/* ... */
}
@end

and:

void someFunction(/* ... */)
{
/* ... */
}

@implementation MyClass
@end


In the former, someFunction is considered to be a part of the  
implementation of the class and is permitted to access private and  
protected ivars of any MyClass instance it may get its hands on.  In  
the latter, someFunction has no particular special relationship to  
MyClass.


Cheers,
Ken
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: private methods and variables

[Ken Thomases]

On Jul 29, 2008, at 6:53 PM, Kyle Sluder wrote:

On Tue, Jul 29, 2008 at 7:30 PM, Torsten Curdt <[EMAIL PROTECTED]>  
wrote:

@implementation MyClass
int privateVariable;
@end

and

int privateVariable;
@implementation MyClass
@end

the first being being an ivar. The second just being a global.
But IIUC now - there really is no difference. That correct?


Did you intend for the first example's ivar to be contained within
braces?  In that case, you were right the first time.


You can't add additional ivars in an @implementation block.  You can  
only redundantly mirror the ivar declarations that were in the  
@interface block which is a waste of typing and doesn't accomplish  
what he was trying to do: declare private instance variables that  
wouldn't appear in the header.


Cheers,
Ken

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: private methods and variables

[Erik Buck]

@implementation MyClass
  int privateVariable;   // this is an instance variable
@end


and

int privateVariable;   // this is a global variable
@implementation MyClass
@end

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: private methods and variables

[Erik Buck]

On Jul 29, 2008, at 7:19 PM, Erik Buck wrote:



@implementation MyClass
 int privateVariable;   // this is an instance variable
@end


and

int privateVariable;   // this is a global variable
@implementation MyClass
@end



Never mind.  both declarations above are global variables.

@interface MyClass : NSObject
{
 int privateVariable;   // this is an instance variable
}

@end


and

extern int privateVariable;   // this is a global variable

@interface MyClass : NSObject
{
}

@end
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: private methods and variables

[Kyle Sluder]

On Tue, Jul 29, 2008 at 7:58 PM, Ken Thomases <[EMAIL PROTECTED]> wrote:
> On Jul 29, 2008, at 6:53 PM, Kyle Sluder wrote:
>> Did you intend for the first example's ivar to be contained within
>> braces?  In that case, you were right the first time.
>
> You can't add additional ivars in an @implementation block.  You can only
> redundantly mirror the ivar declarations that were in the @interface block
> which is a waste of typing and doesn't accomplish what he was trying to do:
> declare private instance variables that wouldn't appear in the header.

Yeah, my brain saw @interface.  Seen the right pattern too much.  :P

--Kyle Sluder
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: private methods and variables

[Torsten Curdt]

Thanks for the clarification folks!

On Jul 30, 2008, at 01:58, Ken Thomases wrote:


On Jul 29, 2008, at 6:53 PM, Kyle Sluder wrote:

On Tue, Jul 29, 2008 at 7:30 PM, Torsten Curdt <[EMAIL PROTECTED]>  
wrote:

@implementation MyClass
int privateVariable;
@end

and

int privateVariable;
@implementation MyClass
@end

the first being being an ivar. The second just being a global.
But IIUC now - there really is no difference. That correct?


Did you intend for the first example's ivar to be contained within
braces?  In that case, you were right the first time.


You can't add additional ivars in an @implementation block.  You can  
only redundantly mirror the ivar declarations that were in the  
@interface block which is a waste of typing and doesn't accomplish  
what he was trying to do: declare private instance variables that  
wouldn't appear in the header.


Cheers,
Ken



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: private methods and variables

[Robert Lang]

I think that's because when you compile the code, if one of your methods
forward references a private method and you haven't declared it in the
interface, you will get a warning.

Also, when you declare privateVariable in the implementation block you are
not declaring it as an instance variable of MyClass but instead as a normal
C variable in global scope.

Best,
Robert

On Tue, Jul 29, 2008 at 10:02 PM, Torsten Curdt <[EMAIL PROTECTED]> wrote:

> This question is NOT about private APIs from Apple but more about how to
> organize structure my own code.
>
> Especially for a framework I don't want to expose implementation details to
> the interface.
> So while I found the suggestion to use a special category like:
>
>  @interface MyClass
>  -(void) publicMethod;
>  @end
>
>  @interface MyClass (Private)
>  {
>int privateVariable;
>  }
>  -(void) privateMethod;
>  @end
>
> I am not sure why that would be better than to just do
>
>  @interface MyClass
>  -(void) publicMethod;
>  @end
>
>  @implementation MyClass
>
>  int privateVariable;
>  -(void) privateMethod {
>  }
>
>  -(void) publicMethod {
>  }
>
>  @end
>
> Any wise words?
>
> cheers
> --
> Torsten
>
>
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: private methods and variables

[Torsten Curdt]

But wait ...this works OK for methods. But what about adding ivars?

 @interface MyClass (Private)
 {
 int myvar;
 }

 - (int) myvar;

 @end

This gives a syntax error. Looking through some docs it seems I cannot  
add ivars through a category.

So how can I have private ivars that don't show up in the interface?

cheers
--
Torsten
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: private methods and variables

[Charles Steinman]

--- On Tue, 7/29/08, Torsten Curdt <[EMAIL PROTECTED]> wrote:

> But wait ...this works OK for methods. But what about adding
> ivars?
> 
>   @interface MyClass (Private)
>   {
>   int myvar;
>   }
> 
>   - (int) myvar;
> 
>   @end
> 
> This gives a syntax error. Looking through some docs it
> seems I cannot  
> add ivars through a category.
> So how can I have private ivars that don't show up in
> the interface?

You can't without hacks like putting a byte blob or pointer at the bottom of 
your class and filling that with extra ivars. Apple does this in its frameworks 
to maintain binary compatibility while still being able to change the structure 
of a class. But unless backward binary compatibility is a concern for you, it's 
easier just to use @private if the variables must be private rather than 
protected.

Cheers,
Chuck


  
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: private methods and variables

[Ken Thomases]

On Jul 29, 2008, at 8:22 PM, Torsten Curdt wrote:


So how can I have private ivars that don't show up in the interface?


You can use the pImpl (pointer-to-implementation) idiom for classes  
that you're writing yourself:


@class MyPrivateStuff;
@interface MyClass : NSObject
{
MyPrivateStuff* pImpl;
}

/* ... */

@end


Then, in your .m file:

@interface MyPrivateStuff : NSObject
{
id foo;
NSString* bar;
/* ... */
};
@end

@implementation MyPrivateStuff
/* ... */
@end

@implementation MyClass

- (id) init
{
if (self = [super init])
{
pImpl = [[MyPrivateStuff alloc] init];
/* ... */
}
}

@end



For classes which you are not writing yourself, you can still extend  
them with categories.  For properties, you add the usual accessor  
methods, which is straightforward with a category.  Providing per- 
instance backing storage for the properties is more complicated.  One  
technique is to use a "category variable" (like the "class variable"  
we were discussing earlier; really just a static file-scope variable)  
to keep an associative collection which maps from "self" to a mutable  
dictionary of property values.  NSMapTable is a good candidate for  
this sort of collection.


Cheers,
Ken
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: private methods and variables

[Torsten Curdt]

Thanks for that!

Really interesting - but also sounds really terrible :)

Makes you wonder why stuff like hasn't been fixed in Objective-C 2.0.

cheers
--
Torsten

On Jul 30, 2008, at 04:03, Ken Thomases wrote:


On Jul 29, 2008, at 8:22 PM, Torsten Curdt wrote:


So how can I have private ivars that don't show up in the interface?


You can use the pImpl (pointer-to-implementation) idiom for classes  
that you're writing yourself:


@class MyPrivateStuff;
@interface MyClass : NSObject
{
MyPrivateStuff* pImpl;
}

/* ... */

@end


Then, in your .m file:

@interface MyPrivateStuff : NSObject
{
id foo;
NSString* bar;
/* ... */
};
@end

@implementation MyPrivateStuff
/* ... */
@end

@implementation MyClass

- (id) init
{
if (self = [super init])
{
pImpl = [[MyPrivateStuff alloc] init];
/* ... */
}
}

@end



For classes which you are not writing yourself, you can still extend  
them with categories.  For properties, you add the usual accessor  
methods, which is straightforward with a category.  Providing per- 
instance backing storage for the properties is more complicated.   
One technique is to use a "category variable" (like the "class  
variable" we were discussing earlier; really just a static file- 
scope variable) to keep an associative collection which maps from  
"self" to a mutable dictionary of property values.  NSMapTable is a  
good candidate for this sort of collection.


Cheers,
Ken


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: private methods and variables

[Bill Bumgarner]

On Jul 29, 2008, at 7:45 PM, Torsten Curdt wrote:

Thanks for that!

Really interesting - but also sounds really terrible :)

Makes you wonder why stuff like hasn't been fixed in Objective-C 2.0.


It has been in the modern runtime -- the runtime used in on 64 bits  
and "other places".  In that environment, the runtime can and will  
@synthesize instance variables and it is possible to add instance  
variables in a private way (but not supported entirely in syntax).


As well, the modern runtime allows a superclass to add instance  
variables without recompiling subclasses.


It isn't fixed in the 32 bit runtime because we couldn't figure out a  
way to do so that both preserved binary compatibility and used a  
finite amount of memory / CPU.


b.bum



smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: private methods and variables

[Ken Thomases]

On Jul 29, 2008, at 10:19 PM, Bill Bumgarner wrote:

It isn't fixed in the 32 bit runtime because we couldn't figure out  
a way to do so that both preserved binary compatibility and used a  
finite amount of memory / CPU.


Well, there's always 6-way Universal binaries.  ;P

Cheers,
Ken
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: private methods and variables

[Bill Bumgarner]

On Jul 29, 2008, at 8:41 PM, Ken Thomases wrote:

On Jul 29, 2008, at 10:19 PM, Bill Bumgarner wrote:
It isn't fixed in the 32 bit runtime because we couldn't figure out  
a way to do so that both preserved binary compatibility and used a  
finite amount of memory / CPU.


Well, there's always 6-way Universal binaries.  ;P


Heh -- true enough -- but it is hard to justify the cost of mapping in  
yet-another-complete-set-of-system dylibs for such purposes.


b.bum



smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: private methods and variables

[Torsten Curdt]

Even more interesting :) Thanks for sharing that Bill.

I've had another idea: Using a protocol would also be a way of  
shielding the framework from the implementation details.
The only problem is that class methods are not allowed in a protocol.  
And the framework's main entry class currently uses a singleton pattern.


cheers
--
Torsten
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: private methods and variables

[Bill Bumgarner]

On Jul 30, 2008, at 12:36 AM, Torsten Curdt wrote:

Even more interesting :) Thanks for sharing that Bill.

I've had another idea: Using a protocol would also be a way of  
shielding the framework from the implementation details.
The only problem is that class methods are not allowed in a  
protocol. And the framework's main entry class currently uses a  
singleton pattern.


Where does it say that protocols can't include class methods?  If  
there is documentation indicating as much then there is a bug  
somewhere and I'd like to know about it.


The following works as expected -- the compiler complains mightily  
about the lack of conformance to protocol Bob in class Fred.


@protocol Bob
+ (void) foo;
@end

@interface Fred : NSObject 
@end
@implementation Fred
@end

---

However, protocols are not generally used to hide implementation  
details.   It sounds more like you want a combination of public and  
private headers / declarations.


For Cocoa, functionality that is supported is made available through  
public headers.  Functionality that is internal to Cocoa is  
encapsulated in private headers that declare said private interfaces  
through a combination of categories, class extensions and full-on  
class declarations.


b.bum

smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: private methods and variables

[Peter N Lewis]

At 11:02 PM +0200 29/7/08, Torsten Curdt wrote:
Especially for a framework I don't want to expose implementation 
details to the interface.


Others have pointed out that you cannot add ivars in the implementation.

However, if you can control the creation of your objects via a 
factory function or other means, then you can have a private subclass 
that has ivars and never actually create the published class per se.


For example (typed in email)

.h file:

@interface MyClass
-(void) publicMethod;

+(MyClass*) allocate;
@end

.m file

@interface MyRealClass : MyClass
{
  int privateVariable;
}
-(void) privateMethod;
@end

@implementation MyClass
-(void) publicMethod { }

+(MyClass*) allocate
{
  return [MyRealClass alloc];
}
@end

@implementation MyRealClass
-(void) privateMethod { }
@end

I've used this technique a fair amount in C++, but, being a novice, 
not much yet in Objective C, but it should work.  I'm not sure 
whether it would be a good idea to for the method named allocate to 
be named alloc or not.  Possibly that would mean it would work even 
if you couldn't control the creation of the class, I'm not sure.


One downside is that Interface Builder does not seem to read .m files 
(even if you actively drag them to it), so you can't have any 
IBOutlets in MyRealClass unless you put it in a (potentially private) 
header file.


Hopefully this makes as much sense in Objective C as it does in C++, 
otherwise I'm sure someone will correct me.


Enjoy,
   Peter.

--
  Keyboard Maestro 3 Now Available!
Now With Status Menu triggers!

Keyboard Maestro  Macros for your Mac
   
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: private methods and variables

[Torsten Curdt]

Where does it say that protocols can't include class methods?  If  
there is documentation indicating as much then there is a bug  
somewhere and I'd like to know about it.


The following works as expected -- the compiler complains mightily  
about the lack of conformance to protocol Bob in class Fred.


@protocol Bob
+ (void) foo;
@end

@interface Fred : NSObject 
@end
@implementation Fred
@end


Got it working now!

I had

@protocol Bob
+ (Bob *)sharedBob; // error: syntax error before 'Bob'
@end // warning: '@end' must appear in an @implementation context

@interface Fred : NSObject 
...
@end

but it needs to be:

@protocol Bob
+ (NSObject *)sharedBob;
@end

However, protocols are not generally used to hide implementation  
details.   It sounds more like you want a combination of public and  
private headers / declarations.


Definitely sounds like that. Basically I have a framework entry  
(public header)


@interface Bob {
 @private
some ivars here
}
+ (Bob *)sharedBob;
- (void)someMethods;
@end

And I would rather have it look like this in public.

@interface Bob
+ (Bob *)sharedBob;
- (void)someMethods;
@end

Still I need those ivars in private though.

For Cocoa, functionality that is supported is made available through  
public headers.  Functionality that is internal to Cocoa is  
encapsulated in private headers that declare said private interfaces  
through a combination of categories, class extensions and full-on  
class declarations.


Any pointers on how this is done?

cheers
--
Torsten
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: private methods and variables

[Jean-Daniel Dupas]

Le 30 juil. 08 à 11:26, Torsten Curdt a écrit :

Where does it say that protocols can't include class methods?  If  
there is documentation indicating as much then there is a bug  
somewhere and I'd like to know about it.


The following works as expected -- the compiler complains mightily  
about the lack of conformance to protocol Bob in class Fred.


@protocol Bob
+ (void) foo;
@end

@interface Fred : NSObject 
@end
@implementation Fred
@end


Got it working now!

I had

@protocol Bob
+ (Bob *)sharedBob; // error: syntax error before 'Bob'
@end // warning: '@end' must appear in an @implementation context

@interface Fred : NSObject 
...
@end

but it needs to be:

@protocol Bob
+ (NSObject *)sharedBob;
@end

However, protocols are not generally used to hide implementation  
details.   It sounds more like you want a combination of public and  
private headers / declarations.


Definitely sounds like that. Basically I have a framework entry  
(public header)


@interface Bob {
@private
   some ivars here
}
+ (Bob *)sharedBob;
- (void)someMethods;
@end

And I would rather have it look like this in public.

@interface Bob
+ (Bob *)sharedBob;
- (void)someMethods;
@end

Still I need those ivars in private though.

For Cocoa, functionality that is supported is made available  
through public headers.  Functionality that is internal to Cocoa is  
encapsulated in private headers that declare said private  
interfaces through a combination of categories, class extensions  
and full-on class declarations.


Any pointers on how this is done?

cheers
--
Torsten


The true question is why you need this ?
I don't see any valid reason to require this kind of constraint.

Now, if you really want something like this, I bet the cleaner way is  
to use class cluster, but it will prevent your framework user to  
subclass Bob.
An other common way is to hide your ivar in an opaque struct (or  
another object with forward declaration only):


@interface Bob {
@private
   struct __OpaqueBobIVars *ivars;
}
+ (Bob *)sharedBob;
- (void)someMethods;
@end


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: private methods and variables

[Torsten Curdt]

Any pointers on how this is done?


The true question is why you need this ?
I don't see any valid reason to require this kind of constraint.


Well, those ivars while private still expose internal classes to the  
interface. I would like to avoid that for encapsulation purposes.


Does that make sense? Or am I going here a little too far?

cheers
--
Torsten
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: private methods and variables

[Michael Ash]

On Wed, Jul 30, 2008 at 6:26 AM, Torsten Curdt <[EMAIL PROTECTED]> wrote:
>>> Any pointers on how this is done?
>>
>> The true question is why you need this ?
>> I don't see any valid reason to require this kind of constraint.
>
> Well, those ivars while private still expose internal classes to the
> interface. I would like to avoid that for encapsulation purposes.
>
> Does that make sense? Or am I going here a little too far?

You're going a little too far. While you're showing it to outsiders,
you're not really *exposing* it, because there's nothing they can
legally do with the knowledge.

Encapsulation just means that outsiders don't rely on internal
implementation details of your class, so that you can change that
implementation without breaking clients. A private or protected
(protected is the default) instance variable, while visible to such
clients, still can't be used by them, so you can change it without
breaking them.

The fact that you have to put it in the header at all is just a quirk
of how the language is implemented. Subclasses need to know the total
size of their superclasses, so all instance variables must go in the
header. But it's still encapsulated, so don't worry about it.

(A big exception: if you are writing code which must remain *binary*
compatible with other code that may subclass your classes, an
exceedingly rare but possible scenario, then you must ensure that the
size of your superclass never grows from one version to the next, even
using private ivars.)

Mike
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: private methods and variables

[Bill Bumgarner]

On Jul 30, 2008, at 2:26 AM, Torsten Curdt wrote:
For Cocoa, functionality that is supported is made available  
through public headers.  Functionality that is internal to Cocoa is  
encapsulated in private headers that declare said private  
interfaces through a combination of categories, class extensions  
and full-on class declarations.


Any pointers on how this is done?


Sure.  Coding in a Compose Window Never Compiles -- you have been  
warned.


Foo.h
-

@class FooPrivateStuff;
@interface Foo : NSObject
{
FooPrivateStuff *privateStuff;
}
... public API here ...
@end

Foo_Private.h
-

@interface FooPrivateStuff:NSObject
{
@protected
... ivars declared here ...
}
@end
@implementation FooPrivateStuff
... you can either decide to manage the ivars in this class OR you  
could simply treat this as a structure and access ivars through ->,  
see below ...


If you want to the ivars to be fully managed by this private class,  
then I would suggest implementing all of the ivars as non-atomic  
properties and synthesized accessors.   Don't forget your -dealloc in  
this case.


Personally, I would go with properties as it allows Foo to use KVO to  
handle change propagation in its internal private state.

@end

@interface Foo() // this is not a category -- a class extension --  
thus all API declared here must be implemented in class

 private API here
@end

Foo.m
-

#import "Foo.h"
#import "Foo_Private.h"

@implementation Foo
- init {
... standard -init dance ...
privateStuff = [FooPrivateStuff new];

// if FooPrivateStuff is just being used as a structure
privateStuff->bob = [Bob new];
privateStuff->count = 10;

// if FooPrivateStuff declared everything as @property
privateStuff.bob = [Bob new];
privateStuff.count = 10;
}

// if not using GC, you'll need this... of course, not using GC is  
generally a waste of time.

- dealloc {
[privateStuff->bob release]; // structure
privateStuff.bob = nil; // @property
[super dealloc];
}



So, why use a class and not a structure?

First, the garbage collector will precisely scan instances -- only  
scanning slots that have object references -- this is more efficient  
and avoids false references.   Secondly, it makes the code easy to  
refactor and enables the use of higher level mechanisms to manage the  
private stuff -- KVO, KVC, etc...   Finally, classes take care of  
allocating enough space for their instance variables across all  
architectures.


b.bum




smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Question about Style wrt "private" methods

[Michael de Haan]

In the newly released "Cocoa design patterns" (Buck and Yacktman), the chapter 
discussing Delegates includes an example, which in it's implementation file, 
has the following method, which is defined/declared like this:  ( I have 
removed the actual definition)


- (float)_myBarShouldChangeValue:(float)newValue
/*! Give the delegate a chance to change the new value */
{
   if(...something)
   {
  more method definition.
   }
   
   return newValue;
}


The method, as alluded to above, is not declared in the interface, and the 
compiler does not complain as it is called from a method later/after this.

The  Authors note:

".The convention of naming so-called private methods with an underscore and 
a prefix reduces the chance that someone might inadvertently override or call 
the method."


I just wonder how this meshes with Apple's documentation:  (Private methods in 
"Coding guidelines for Cocoa")

"Names of most private methods in the Cocoa frameworks have an underscore 
prefix (for example, _fooData ) to mark them as private. From this fact follow 
two recommendations.

• Don’t use the underscore character as a prefix for your private 
methods. Apple reserves this convention."


I have hunted around for a thread in cocoa, which I was looking at, ( and of 
course which I cannot find now)  that implied that "extensions" seemed to be 
the way that this should be addressed. 

I am not asking to start another huge thread, but, seeing that this has 
**just** been published, and in every other way is providing a really solid 
approach (for me)  to Cocoa, and trying to start out "right", is there an easy 
answer to the seemingly contradictory advice, or it is just possible/likely,  
that I have missed some very important issues.

Thanks in advance.








___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Question about Style wrt "private" methods

[Jens Alfke]

On Nov 18, 2009, at 9:44 AM, Michael de Haan wrote:

> "Names of most private methods in the Cocoa frameworks have an underscore 
> prefix (for example, _fooData ) to mark them as private. From this fact 
> follow two recommendations.
> 
>   • Don’t use the underscore character as a prefix for your private 
> methods. Apple reserves this convention."

This is unfortunately true. The danger is that if you add an _-prefixed method 
to your class, it might conflict with a private method declared in a 
superclass. If this happens your method will override the internal one, and 
Really Bad Things will probably happen. It's a rare problem but it has happened 
before. (And even if everything works well now, any future OS update might add 
a new private method in a superclass that breaks your code. Again, this has 
actually happened.)

Using a naming convention for your private/internal methods is a good idea; 
just use a different convention. I've seen people use an "i_" prefix, for 
example.

—Jens___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Question about Style wrt "private" methods

[Jim Correia]

On Nov 18, 2009, at 1:49 PM, Jens Alfke wrote:

This is unfortunately true. The danger is that if you add an _- 
prefixed method to your class, it might conflict with a private  
method declared in a superclass. If this happens your method will  
override the internal one, and Really Bad Things will probably  
happen. It's a rare problem but it has happened before. (And even if  
everything works well now, any future OS update might add a new  
private method in a superclass that breaks your code. Again, this  
has actually happened.)


This problem is just not restricted to private methods, or additions  
through categories. You can also run afoul of a namespace conflict  
with a public method in your subclass.


Suppose you have a subclass of NSView which adds - 
reallyNiceMethodThatOughtToBeInAppKit. If Apple adds such a method in  
the next OS release, the same kinds of problem can result. (Similar  
problems when you extend delegate protocols for your subclasses too.)


This problem is much less insidious than the category problem, but the  
potential does exist. (For both private and public methods.)


- Jim

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Question about Style wrt "private" methods

[Jens Alfke]

On Nov 18, 2009, at 11:15 AM, Jim Correia wrote:

> This problem is just not restricted to private methods, or additions through 
> categories. You can also run afoul of a namespace conflict with a public 
> method in your subclass.

Yes; but this is less likely because Apple engineers add public methods less 
often (almost never in minor updates) and more carefully.

(It would be nice if Obj-C had some sort of namespaces for methods, and it's 
been discussed, but it sort of conflicts with the dynamic nature of the 
language. Every message has to have a single canonical name at runtime; if you 
think about the implications for selector names in source code and in IB, you 
can see how it would get messy.)

—Jens___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Question about Style wrt "private" methods

[Jim Correia]

On Nov 18, 2009, at 2:32 PM, Jens Alfke wrote:

> On Nov 18, 2009, at 11:15 AM, Jim Correia wrote:
> 
>> This problem is just not restricted to private methods, or additions through 
>> categories. You can also run afoul of a namespace conflict with a public 
>> method in your subclass.
> 
> Yes; but this is less likely because Apple engineers add public methods less 
> often (almost never in minor updates) and more carefully.

Agreed. Subtle breakage is still possible across a major release when both you 
and Apple choose the obvious name for new functionality.

-isHidden/-setHidden: on NSView is the sort of thing (which was added recently 
enough that many people likely remember it.)

If you had subclassed NSView to add that functionality, its pretty likely you 
would have chose those names, or -isVisible/-setVisibible: because they are the 
obvious solution to the problem.

You can avoid namespace clash altogether by writing ugly code, with names no 
one would ever want to use for your methods and properties. But who wants to do 
that? :-)

Jim___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Question about Style wrt "private" methods

[Michael de Haan]

On Nov 18, 2009, at 11:15 AM, Jim Correia wrote:

> On Nov 18, 2009, at 1:49 PM, Jens Alfke wrote:
> 
>> This is unfortunately true. The danger is that if you add an _-prefixed 
>> method to your class, it might conflict with a private method declared in a 
>> superclass. If this happens your method will override the internal one, and 
>> Really Bad Things will probably happen. It's a rare problem but it has 
>> happened before. (And even if everything works well now, any future OS 
>> update might add a new private method in a superclass that breaks your code. 
>> Again, this has actually happened.)
> 
> This problem is just not restricted to private methods, or additions through 
> categories. You can also run afoul of a namespace conflict with a public 
> method in your subclass.
> 
> Suppose you have a subclass of NSView which adds 
> -reallyNiceMethodThatOughtToBeInAppKit. If Apple adds such a method in the 
> next OS release, the same kinds of problem can result. (Similar problems when 
> you extend delegate protocols for your subclasses too.)
> 
> This problem is much less insidious than the category problem, but the 
> potential does exist. (For both private and public methods.)
> 
> - Jim
> 
> 

Thanks to all who answered for you insights.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Question about Style wrt "private" methods

[Sean McBride]

On 11/18/09 2:15 PM, Jim Correia said:

>This problem is much less insidious than the category problem, but the
>potential does exist. (For both private and public methods.)

For the category case, you can set the environment variable
OBJC_PRINT_REPLACED_METHODS=YES.
You'll get something like this:

objc[60273]: REPLACED: -[NSArray firstObject]  by category RRExtra  (IMP
was 0x9612d970 (/System/Library/Frameworks/CoreFoundation.framework/
Versions/A/CoreFoundation), now 0x21b50e (/path/to/myapp))

--

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com
Mac Software Developer  Montréal, Québec, Canada


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com