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
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
> > 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
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
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
> 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
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
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
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
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
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
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.
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
___
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
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
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
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
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.
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
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
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
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
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
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? :-
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
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? :-)
>
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
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
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
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
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
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
32 matches
Mail list logo
