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
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
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
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
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
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
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
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
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
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
_
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
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
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
--- 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
>
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
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
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
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
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
@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
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
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
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
@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
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
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
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
27 matches
Mail list logo
