Re: Private Methods

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

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 o

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 underscor

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

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

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

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 o

Private Methods

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

Re: Subclassing and private methods

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

Re: Subclassing and private methods

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

Re: Subclassing and private methods

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

Subclassing and private methods

(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

Re: Question about Style wrt "private" methods

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:

Re: Question about Style wrt "private" methods

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 subc

Re: Question about Style wrt "private" methods

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

Re: Question about Style wrt "private" methods

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 a

Re: Question about Style wrt "private" methods

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 me

Re: Question about Style wrt "private" methods

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 c

Question about Style wrt "private" methods

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 do

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

private methods and variables

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

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

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

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

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

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

Re: Private Methods

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 ag

Re: Private Methods

. 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

Re: Private Methods

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 metho

Re: Private Methods

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

Re: Private Methods

y 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

Re: Private 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

Re: Private Methods

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

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

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

Private Methods

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