Re: Private ivars, not marked as IBOutlet, visible in IB

2010-03-15 Thread David Duncan
On Mar 15, 2010, at 3:49 PM, Jeff Laing wrote: > But my protocol only wanted to define the methods in my protocol - a nice > clean Interface definition that's independent of all other definitions. > After all, Apple might add some non-optional methods to NSObject (ok, that's > unlikely) that a

Re: Private ivars, not marked as IBOutlet, visible in IB

2010-03-15 Thread Greg Parker
On Mar 15, 2010, at 3:35 PM, David Duncan wrote: > On Mar 15, 2010, at 3:22 PM, Jeff Laing wrote: >> As I recall, sending variables of type id useful messages like >> retain and release generate a compiler warning, whereas >> NSObject are fine. >> >> I could be wrong on this, but I definitely re

RE: Private ivars, not marked as IBOutlet, visible in IB

2010-03-15 Thread Jeff Laing
> > I could be wrong on this, but I definitely recall thinking it was a > stupid compiler behavior. > > This is because you didn't declare your protocol as extending the > NSObject protocol. If you do something like this: > > @protocol MyProtocol > > Then you can call all the NSObject stuff with

Re: Private ivars, not marked as IBOutlet, visible in IB

2010-03-15 Thread Alexander Spohr
Am 15.03.2010 um 23:22 schrieb Jeff Laing: > As I recall, sending variables of type id useful messages like > retain and release generate a compiler warning, whereas > NSObject are fine. > > I could be wrong on this, but I definitely recall thinking it was a stupid > compiler behavior. You c

Re: Private ivars, not marked as IBOutlet, visible in IB

2010-03-15 Thread David Duncan
On Mar 15, 2010, at 3:22 PM, Jeff Laing wrote: > As I recall, sending variables of type id useful messages like > retain and release generate a compiler warning, whereas > NSObject are fine. > > I could be wrong on this, but I definitely recall thinking it was a stupid > compiler behavior. Th

RE: Private ivars, not marked as IBOutlet, visible in IB

2010-03-15 Thread Jeff Laing
> Not necessarily true. While you are free to specify a delegate as > NSObject , it is not standard convention. The convention > for delegates is: id. As I recall, sending variables of type id useful messages like retain and release generate a compiler warning, whereas NSObject are fine. I cou

Re: Private ivars, not marked as IBOutlet, visible in IB

2010-03-13 Thread Alexander Spohr
Am 13.03.2010 um 18:54 schrieb Joanna Carter: >> Actually this is how nibs were designed and intended to be used: to be >> fragments of the object graph loaded at runtime. It is a *very* recent >> trend to have them exist so independently of File's Owner, and to use >> the public API to hook up t

Re: Private ivars, not marked as IBOutlet, visible in IB

2010-03-13 Thread Alexander Spohr
You are right, id is the standard. But the question was how to get a delegate that is not visible in IB and does not produce compiler warnings. atze Am 13.03.2010 um 18:55 schrieb Kevin Cathey: > Not necessarily true. While you are free to specify a delegate as NSObject > , it is not

Re: Private ivars, not marked as IBOutlet, visible in IB

2010-03-13 Thread Kevin Cathey
Not necessarily true. While you are free to specify a delegate as NSObject , it is not standard convention. The convention for delegates is: id. Kevin On 13 Mar 2010, at 07:39, Alexander Spohr wrote: > > Am 13.03.2010 um 16:25 schrieb Joanna Carter: > >> My reason for using id is because I

Re: Private ivars, not marked as IBOutlet, visible in IB

2010-03-13 Thread Joanna Carter
Hi Kyle > Actually this is how nibs were designed and intended to be used: to be > fragments of the object graph loaded at runtime. It is a *very* recent > trend to have them exist so independently of File's Owner, and to use > the public API to hook up their connections. So I gather. Which was o

Re: Private ivars, not marked as IBOutlet, visible in IB

2010-03-13 Thread Kyle Sluder
On Sat, Mar 13, 2010 at 7:20 AM, Joanna Carter wrote: >> If my class is files owner the whole nib is owned by it - hence the name. >> Therefore I absolutely want IB to be able to set even the private ivars. The >> nib is just another way of setting up my class’ objects. > > If I may say so, to s

Re: Private ivars, not marked as IBOutlet, visible in IB

2010-03-13 Thread Joanna Carter
Hi Alexander > Yes your idea is wrong. > You are free to specify NSObject *delegate; Great. I've learnt so much but there is still so much more to learn :-) Joanna -- Joanna Carter Carter Consulting ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.

Re: Private ivars, not marked as IBOutlet, visible in IB

2010-03-13 Thread Alexander Spohr
Am 13.03.2010 um 16:25 schrieb Joanna Carter: > My reason for using id is because I want to hold a delegate and call methods > on it without compiler warnings. Or have I got the wrong idea there? Yes your idea is wrong. You are free to specify NSObject *delegate; atze ___

Re: Private ivars, not marked as IBOutlet, visible in IB

2010-03-13 Thread Joanna Carter
Hi Roland Le 13 mars 2010 à 12:13, Roland King a écrit : > I don't know if Joanna was suggesting you couldn't make anything available to > IB by making it an IBOutlet, I took it that she was saying the old > 'compatibility mode' of having any variable of type 'id', even if not an > IBOutlet, b

Re: Private ivars, not marked as IBOutlet, visible in IB

2010-03-13 Thread Joanna Carter
Hi Paul Le 13 mars 2010 à 12:12, Paul Sanders a écrit : > Try: > > #define PRIVATE_ID id > > ... > > PRIVATE_ID myPrivateiVar; Hmmm, messy. I much prefer the developer tools to respect the visibility specifier. :-) Joanna -- Joanna Carter Carter Consulting

Re: Private ivars, not marked as IBOutlet, visible in IB

2010-03-13 Thread Joanna Carter
Hi Alexander > If my class is files owner the whole nib is owned by it - hence the name. > Therefore I absolutely want IB to be able to set even the private ivars. The > nib is just another way of setting up my class’ objects. If I may say so, to say this is to misunderstand object oriented des

Re: Private ivars, not marked as IBOutlet, visible in IB

2010-03-13 Thread Roland King
I don't know if Joanna was suggesting you couldn't make anything available to IB by making it an IBOutlet, I took it that she was saying the old 'compatibility mode' of having any variable of type 'id', even if not an IBOutlet, be visible in IB would not be broken if you restricted it to those

Re: Private ivars, not marked as IBOutlet, visible in IB

2010-03-13 Thread Paul Sanders
Try: #define PRIVATE_ID id ... PRIVATE_ID myPrivateiVar; Paul Sanders. ___ 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.

Re: Private ivars, not marked as IBOutlet, visible in IB

2010-03-13 Thread Alexander Spohr
Am 13.03.2010 um 10:32 schrieb Joanna Carter: > All that is needed is to detect whether the ivar is @private and to respect > that visibility. If an ivar is private, it should not be visible in the IB > designer, regardless of whether it is of type id or not. I’d say no to this. If my class i

Re: Private ivars, not marked as IBOutlet, visible in IB

2010-03-13 Thread Joanna Carter
Hi Thomas > Which is something some people at Apple encourage not to do. The leading > underscore is seen as "Library implementors naming space" (also and > especially for method signatures) so your code might break when you use that > coding pattern. > > OTOH, enforcing would break many peop

Re: Private ivars, not marked as IBOutlet, visible in IB

2010-03-13 Thread Thomas Engelmeier
Am 04.03.2010 um 19:58 schrieb Joanna Carter: > I have no problem with this concept of default behaviour, if it is for legacy > purposes but, with the new visibility specifiers, these should take > precedence of the older legacy rules. > > Never mind, as long as you prepend the private ivar wi

Re: Private ivars, not marked as IBOutlet, visible in IB

2010-03-04 Thread Joanna Carter
Le 4 mars 2010 à 16:31, Lynn Barton a écrit : > Buck and Yacktman's book Cocoa Design Patterns says on page 208, "Any > instance variable with type id and a name that doesn't start with an > underscore character is automatically considered an outlet." That is understandable... if the ivars hav

Re: Private ivars, not marked as IBOutlet, visible in IB

2010-03-04 Thread Lynn Barton
Buck and Yacktman's book Cocoa Design Patterns says on page 208, "Any instance variable with type id and a name that doesn't start with an underscore character is automatically considered an outlet." Lynn ___ Cocoa-dev mailing list (Cocoa-dev@lists.ap

Re: Private ivars, not marked as IBOutlet, visible in IB

2010-03-01 Thread Shane Stanley
On 2/3/10 3:36 AM, "Joanna Carter" wrote: >> That is a legacy of Interface Builder on NextStep, from the days before the >> IBOutlet marker was added. > > Heheh, I was afraid if that. Surely it's about time, with all the other > breaking changes for Snow Leopard, that that got broken as well? :-

Re: Private ivars, not marked as IBOutlet, visible in IB

2010-03-01 Thread Jens Alfke
In most cases there are better types to use than 'id' for an ivar. Using a specific class or protocol will get you type-checking. If it's something like a delegate and you don't care what class it is but will be sending one or two specific messages to it, you can create an @protocol containing t

Re: Private ivars, not marked as IBOutlet, visible in IB

2010-03-01 Thread Joanna Carter
Hi Henry > Not a bug --- a Feature . . . > > That is a legacy of Interface Builder on NextStep, from the days before the > IBOutlet marker was added. Heheh, I was afraid if that. Surely it's about time, with all the other breaking changes for Snow Leopard, that that got broken as well? :-) >

Re: Private ivars, not marked as IBOutlet, visible in IB

2010-03-01 Thread Henry McGilton
On Mar 1, 2010, at 4:40 AM, Joanna Carter wrote: > I have discovered that adding a private ivar of type id to a class makes it > visible as an IBOutlet in Interface Builder. > > @interface MyController : NSObject > { > @private > id anIvar; > > ... > } > > @end > > Is this a known bug, or

Re: Private ivars, not marked as IBOutlet, visible in IB

2010-03-01 Thread Joanna Carter
Le 1 mars 2010 à 13:13, Roland King a écrit : > http://bugreport.apple.com > > you need at least some kind of apple developer ID, free one is fine. Thanks. Reported #7701200. Joanna -- Joanna Carter Carter Consulting ___ Cocoa-dev mailing list (Co

Re: Private ivars, not marked as IBOutlet, visible in IB

2010-03-01 Thread Roland King
http://bugreport.apple.com you need at least some kind of apple developer ID, free one is fine. On 01-Mar-2010, at 9:10 PM, Joanna Carter wrote: > Le 1 mars 2010 à 12:59, Roland King a écrit : > >> I can't find this in the Apple documentation (it says that you need >> IBOutlet) however I beli

Re: Private ivars, not marked as IBOutlet, visible in IB

2010-03-01 Thread Joanna Carter
Le 1 mars 2010 à 12:59, Roland King a écrit : > I can't find this in the Apple documentation (it says that you need IBOutlet) > however I believe that the nutshell cocoa guide stated that to be the case. > > Doesnt have to be private actually, just id seems to be enough. > > It has that 'lega

Re: Private ivars, not marked as IBOutlet, visible in IB

2010-03-01 Thread Roland King
I can't find this in the Apple documentation (it says that you need IBOutlet) however I believe that the nutshell cocoa guide stated that to be the case. Doesnt have to be private actually, just id seems to be enough. It has that 'legacy' feel about it. On 01-Mar-2010, at 8:40 PM, Joanna Car

Private ivars, not marked as IBOutlet, visible in IB

2010-03-01 Thread Joanna Carter
I have discovered that adding a private ivar of type id to a class makes it visible as an IBOutlet in Interface Builder. @interface MyController : NSObject { @private id anIvar; ... } @end Is this a known bug, or expected behaviour? Joanna -- Joanna Carter Carter Consulting