Re: Private Methods

>> 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

Re: Private Methods

> 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 extens

Re: Private Methods

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 f

Re: Private Methods

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

Re: Private Methods

> 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

Re: Private Methods

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 C

Re: Private Methods

> 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

Re: Private Methods

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

Re: Private Methods

> 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 CALa

Re: Private Methods

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

Re: Private Methods

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,

Re: Private Methods

> 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 whi

Re: Private Methods

> 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

Re: Private Methods

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,

Re: Private Methods

> 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

Re: Private Methods

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.

Re: Private Methods

> 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

Re: Private Methods

> 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 C

Re: Private Methods

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. A

Re: Private Methods

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:

Re: Private Methods

> 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 larg

Re: Private Methods

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

Re: Private Methods

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

Re: Private Methods

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 m

Re: Private Methods

> 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 subcl

Re: private methods and variables

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 e

Re: private methods and variables

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

Re: private methods and variables

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

Re: private methods and variables

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 abou

Re: private methods and variables

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

Re: private methods and variables

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 o

Re: private methods and variables

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 protoc

Re: private methods and variables

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 u

Re: private methods and variables

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-w

Re: private methods and variables

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 _

Re: private methods and variables

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 e

Re: private methods and variables

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

Re: private methods and variables

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 { MyPrivateS

Re: private methods and variables

--- 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 >

Re: private methods and variables

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

Re: private methods and variables

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

Re: private methods and variables

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; @implemen

Re: private methods and variables

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 @impleme

Re: private methods and variables

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 My

Re: private methods and variables

@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 adm

Re: private methods and variables

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. Bu

Re: private methods and variables

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 II

Re: private methods and variables

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 n

Re: private methods and variables

@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 l

Re: private methods and variables

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 spe

Re: private methods and variables

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 @imple

Re: Private Methods

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

Re: Private Methods

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 de

Re: Private Methods

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) Pl

Re: Private Methods

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];

Re: Private Methods

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

Re: Private Methods

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 hav

Re: Private Methods

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

Re: Private Methods

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.

Re: Private Methods

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 descript

Re: Private Methods

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 interes

Re: Private Methods

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 h

Re: Private Methods

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. A

Re: Private Methods

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 develope

Re: Private Methods

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 co

Re: Private Methods

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

Re: Private Methods

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

Re: Private Methods

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