discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Ghack - GNUstep roguelike


From: Ivan Vučica
Subject: Re: Ghack - GNUstep roguelike
Date: Thu, 14 Mar 2013 10:29:16 +0100

On 13. 3. 2013., at 12:07, Turtle Wizard <NOSPAM@gmail.com> wrote:

Well, even on GNUstep it is wrong to initialize an object that is already initialized.

And the [Class new] method is a shortcut for [[Class alloc] init].

i.e. you have to replace

[[[Class alloc] init] initWithString:...]


You can overload class and instance methods with an id or pointer, it just overloads no
alloc it returns a self, this is possible in SmallTalk, I don't see any reason why
this should not work. It's a sort of subclass responsability.

Hi Fyndhorn!

I'm not sure you get what Nikolaus is pointing out :-)

[ClassNameHere alloc] - allocates memory for class instance's struct, and then memset()s it to zero.
[instanceOfClassNameHere init] - takes the zero-outed class instance's struct, and initializes it in a class-appropriate way

[ClassNameHere new] - equivalent to [[ClassNameHere alloc] init]
[[ClassNameHere new] init] - equivalent to [[[ClassNameHere alloc] init] init]

While you are allowed to not stick to these conventions, and while classes might not stick to them, that is very, very, VERY frowned upon. It breaks code readability, developer expectations, and makes introduction of bugs far easier.

Calling init on a class instance that is already initialized (for example: [[NSMutableString new] init], a semantical equivalent of [[[NSMutableString alloc] init] init]) is a bug. Don't do it. If it works, it's by accident, not by design.

Class implementation can count on init not being called more than once for a particular class instance, and if it is, anything may happen: memory leaks, resource leaks, crashes -- anything goes.

Finally, to go back in discussion a few steps: if you're writing for GNUstep, you're already showing that you care about your freedom and your users' freedom, including freedom to run on a wider variety of platforms. And if you're writing for GNUstep, being portable is very, very easy, so there is little reason for not being portable to Cocoa. 

Regarding Cocoa/GNUstep and iOS code: indeed, you will need to have portions of code separately written for different UI toolkits. You might be able to reuse parts, though. Yet, the difference between GNUstep and OS X is sufficiently small that if you target GNUstep and use Apple's documentation to check that stuff you use exists -- a good idea no matter what you do -- you're almost automatically targeting Cocoa.

Thanks for your work on an interesting project :-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]