Re: Cocoa et al as HCI usability problem
Hi, Sincerely, I am coding under windows with Win32/Qt/Corba/Lua and others for a living, I use MSDN every day, I read their example very often. Well Qt has a very usable API and a good documentation and good examples and we have access to the sources... But on the Win32/Microsoft front, I don't think that the doc is so well written at all, and they had a lot more money to put it behind this task. Ok, hopefully you can find a lot of useful stuff on lot of web site (code guru...), but the Microsoft documentation suck, sincerely. I agree that the Cocoa doc 2/3 years ago was not good at all, that's true. Now the doc team has made a very nice job and the doc has a lot improved. A lot of conceptual text. You can start easily. Obviously, they can make it better,it need time. something like : xcode documentation --> Cocoa --> Getting Started et voila and you start reading the doc, you can print it and read it in the public transport to do it in your spare time... :) Maybe people are to used to code without understanding it with the help of code completion... I suppose that Apple need to put more people on this front to get it better, but it would reduce their business profit :( I was reading in public transport, every day, the documentation of NeXTSTEP 0.8 18 year ago, that's funny :) I agree that at this time it took me 6 months to get the Aha! moment, but I didn't have a NeXT computer at work, hence reading the documentation was the sole thing I was able to do. Have fun Gerard >I'm not against hard work to learn a new platform/language. Its a >challenge and I love it. The problem I have is that the docs as >written do not work for learning Cocoa in your spare time even if you >plan to go full-time to Cocoa in the future (that's my goal - move my >WinMobile dev to my other engineers and then move myself to Cocoa full- >time, but I can't just drop my projects now). And I think this quote >from Peter Duniho explain exactly why: > >> MSDN is sprinkled with code samples. Everywhere. Granted, some of >> them are kind of silly, and some of them are just plain wrong. But >> on the whole, they are pretty good. More to the point, they exist >> for pretty much _every_ documented API element. Class methods, ___ 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.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Cocoa et al as HCI usability problem
>I admit, there are lots of people who don't mind dangerous >programming environments. Some people even thrive on them. But me? >I've had enough of the danger. I've lived my life on the edge long >enough, and I'm ready for a nice, quiet language when it's available. Stay with the M$ way then, it seems to me the less adventurous choice today It is a question of intellectual curiosity I believe, maybe you are too old and tired to take new risk and have more fun ? >disturb me are REALLY minor relative to the other stuff. If Xcode >and IB and the documentation worked perfectly, I could easily >overlook how Objective-C works. I know that it can be biased, but I am using every day Visual 2003 for my job, producing C++ code, and sincerely, I don't find the tools and doc superior to the MacOSX ones. Maybe it has more sense to use them when programming C#/.Net code, I don't know. I had to explore .Net to integrate a .Net component in our Qt/trolltech project, to do Olap stuff, I was frightened by the state of the documentation for the .Net components, the learning curve was very unfriendly. I don't like everything in Cocoa/Xcode/IB, but I feel that your criticism are a bit artificial here. All of us have a lot of different experience in programming; we have to fight with hostile environment sometimes, it is our job : I maintain the server part of our product under solaris, with sunstudio 11 and other tools like xemacs and co... Xcode is very easy to use, navigating in the project is very efficient, the doc is well formed, IB is very powerful, and the tool are improving a lot every time a version is out. Regards Gerard ___ 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.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Cocoa et al as HCI usability problem
>denial of anything. Lowering the barriers to entry doesn't necessarily >serve them or their consumers better, it serves new developers who see >the iPhone as an opportunity but, obviously, there is no shortage of >people wanting to take advantage of that opportunity, so I'm not sure Good point, the things that matters is market share, the PS2 was a nightmare to develop for but it has not dissuaded companies to make games for. Look at the things done with jail-broken iPhone/iPod, no documentation, only classdump and nm etc... Obviously, a good documentation is very important in the long run, and I am pretty happy to see that Tools, ObjC and Docs have so matured :) Regards Gerard ___ 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.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Trying to understand -- please help...
Well
Something like this is standard :
- (id)init
{
if (!(self = [super init]))
return nil;
cityArray = [[NSArray alloc] initWithObjects:
@"New York"
...,
nil];
return self;
}
would work.
In fact in its original case, there would be a crash, because cityArray would
point to a trashed pointer... I don't understand why it is not crashing.
Maybe du to a bad initialization because of the miss of [super init] ???
Gerard Iglesias
Le 21/05/08 à 18:31, "Hank Heijink (Mailinglists)" <[EMAIL PROTECTED]> a écrit :
>
>On May 21, 2008, at 12:05 PM, john darnell wrote:
>
>> - (id) init
>> {
>> cityArray = [[NSArray alloc] init];
>> NSString *c0 = @"New York"; //Ten NSString objects created here
>> ...
>> NSString *c9 = @"Virginia Beach";
>> cityArray = [NSArray arrayWithObjects: c0, ...c9, nil];
>> return self;
>> }
>
>Here's your problem. First, you allocate and initialize the cityArray
>with an empty NSArray (not very useful, since you can't add items to
>an NSArray). Then, you leak that allocated memory by setting cityArray
>to an autoreleased NSArray - this is the one that's going to disappear
>when you exit the method. You should replace your method by something
>like this:
>
>- (id) init
>{
> NSString *c0 = @"New York"; //Ten NSString objects created here
> ...
> NSString *c9 = @"Virginia Beach";
> cityArray = [[NSArray alloc] initWithObjects: c0, ...c9, nil];
> return self;
>}
>
>You can also dispense with the NSString objects by inserting the
>string constants in the array itself:
>
>cityArray = [[NSArray alloc] initWithObjects: @"New York", ...,
>@"Virginia Beach", nil];
>
>Hope this helps!
>
>Hank
>
>___
>
>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.apple.com
>
>Help/Unsubscribe/Update your Subscription:
>http://lists.apple.com/mailman/options/cocoa-dev/gerard_iglesias%40mac.com
>
>This email sent to [EMAIL PROTECTED]
>
>
___
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.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: Trying to understand -- please help...
>with an empty NSArray (not very useful, since you can't add items to >an NSArray). Then, you leak that allocated memory by setting cityArray >to an autoreleased NSArray In fact it is not leaking, it is just creating an object for nothing, it will be released by the autorelease pool, than no leaks :) Gerard ___ 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.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Trying to understand -- please help...
Le 21/05/08 à 19:03, "Clark Cox" <[EMAIL PROTECTED]> a écrit : >On Wed, May 21, 2008 at 9:49 AM, Gérard Iglesias ><[EMAIL PROTECTED]> wrote: >>>with an empty NSArray (not very useful, since you can't add items to >>>an NSArray). Then, you leak that allocated memory by setting cityArray >>>to an autoreleased NSArray >> >> In fact it is not leaking, it is just creating an object for nothing, it >> will be released by the autorelease pool, than no leaks :) > >No, it is indeed leaking (assuming that garbage collection is not being used). > >The array returned by [[NSArray alloc] init] is not autoreleased, and >the caller is responsible for releasing it when through with it. You are right, in the initial code... cityArray = [[NSArray array] init]; But the sentence : Then, you leak that allocated memory by setting cityArray to an autoreleased NSArray is wrong... By reading it I understand the code : [NSArray array] not ? Or am I missing something ? Gerard ___ 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.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Cocoa et al as HCI usability problem
Le 23/05/08 à 15:26, "Ilan Volow" <[EMAIL PROTECTED]> a écrit : >IMHO Objective-C 2.0 looks like Apple's attempt to make Objective-C >competitive with existing scripting languages, given the addition of >the dot syntax for accessors and garbage collection changes. No scripting languages, maybe Java and C#, I think :) Gerard ___ 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.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
