A friend pointed me to a *really* interesting documentation browser with
features along these lines. (Classes and methods have their own wiki pages is
what reminded me of this old thread on cocoa-dev, but there's lots more.) I've
only played with it a bit, but it seems very sharp and
On May 20, 2008, at 10:46 AM, Bill Bumgarner wrote:
On May 20, 2008, at 1:07 AM, Peter Duniho wrote:
But personally, it makes me nervous to have a language that allows
the implementation of a class to change according to other code not
related to the class. It's one thing if you're just
On 23 May 2008, at 01:38, [EMAIL PROTECTED] wrote:
On May 22, 2008, at 11:15 AM, Jonathan Hendry wrote:
Perhaps a better way of doing this would be a web or WebKit app with
two panes. One that shows the Apple docs at Apple's site, and the
other pane points to a page at a non-Apple wiki site
On May 23, 2008, at 2:23 AM, Gerriet M. Denkmann wrote:
1. For me the documentation would be very hard to use without the
excellent AppKiDo.
2. It really should be Apple's job to provide something like AppKiDo.
There is new browsing facilities in Xcode 3.0. Research Assistant,
and
On Fri, May 23, 2008 at 4:30 PM, Sherm Pendley [EMAIL PROTECTED] wrote:
Obviously - but *which* Cocoa developers? I suspect that many veterans would
categorize these additions as premature optimization - I can't speak for
anyone else, but it's been years since I needed to write an accessor
On Fri, May 23, 2008 at 4:45 AM, Michael Ash [EMAIL PROTECTED] wrote:
On Fri, May 23, 2008 at 4:30 PM, Sherm Pendley [EMAIL PROTECTED]
wrote:
Does this sound similar? Objective-C obviously already has access
limiters,
but disassociating the object and property storage would eliminate the
On 22 May 2008, at 23:19, Scott Anguish wrote:
On May 22, 2008, at 10:39 AM, Julius Guzy wrote:
On 22 May 2008, at 4:55, David Casseres wrote:
That's a really good idea, your wiki-that's-more-than-a-wiki.
You're in charge!
8^{)
Ha Ha
But just as a matter of interest, how would one
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.
Given that the real strength of scripting languages is tons of useful
community supplied
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
On May 22, 2008, at 9:36 PM, Graham Cox wrote:
On 23 May 2008, at 3:20 am, Andy Lee wrote:
That may be, but that is different from demanding that Apple lower
the barriers by changing Cocoa itself to resemble those platforms.
I think many of the additions in Object-C 2.0 and the addition of
On May 22, 2008, at 11:21 PM, Bill Bumgarner wrote:
The design goals of properties and GC were to make Cocoa developers
more productive and to give Cocoa developers a better set of tools
to take advantage of modern Macintosh hardware. That the
technologies lower the barriers to entry is
On 23 May 2008, at 11:49, Ken Thomases wrote:
On May 23, 2008, at 3:09 AM, Gerriet M. Denkmann wrote:
I do seem to remember that there was something to write files and
folders to a CDs using an Objective-C interface.
- entered disk into AppKido - nothing except NSURLCache.
- entered disk
Sherm Pendley wrote:
I think Apple is interested in making Cocoa in general more
competitive, not just Objective-C. In fact, I suspect that their
recent
increased interest in supporting scripting bridges for Cocoa may be
at least
partly motivated by a need to compete with .NET's
On Fri, May 23, 2008 at 5:34 PM, Bill Bumgarner [EMAIL PROTECTED] wrote:
On May 23, 2008, at 3:49 PM, Sherm Pendley wrote:
The implementation of foreach appears almost expressly designed to better
support scripting languages. The ObjC foreach() syntax is just chrome -
the
fast comes from
The documentation is for the most part oriented around the
implementation of the technologies offered (inside out view) rather
than the solving of the challenged faced (outside in view). For
experts this is no great barrier, because they are already arguably
inside. But see how this
On Fri, May 23, 2008 at 5:58 PM, has [EMAIL PROTECTED] wrote:
Sherm Pendley wrote:
I think Apple is interested in making Cocoa in general more
competitive, not just Objective-C. In fact, I suspect that their recent
increased interest in supporting scripting bridges for Cocoa may be at
On Sat, May 24, 2008 at 5:21 AM, glenn andreas [EMAIL PROTECTED] wrote:
While properties are nice, it's the for each thing that really is thing I
miss most when not working in ObjC 2.0... (if only the equivalent
NSEnumerator based loop were automatically generated in non ObjC 2.0)
If you
On May 23, 2008, at 9:19 PM, Graham Cox wrote:
On 24 May 2008, at 7:34 am, Bill Bumgarner wrote:
The NSEnumerator stuff is prone to introducing silly errors, is
inefficient, and not very pleasant to look at.
Can you go into more detail about the efficiency improvements? I do
use a lot
On May 23, 2008, at 9:19 PM, Graham Cox wrote:
On 24 May 2008, at 7:34 am, Bill Bumgarner wrote:
The NSEnumerator stuff is prone to introducing silly errors, is
inefficient, and not very pleasant to look at.
Can you go into more detail about the efficiency improvements? I do
use a lot of
Nice graphs!
On May 23, 2008, at 9:39 PM, Adam R. Maxwell wrote:
I did some crude benchmarking a while back and found that
NSFastEnumeration was roughly the same as using
CFArrayGetValueAtIndex() in a loop, and both were faster than using
NSEnumerator or -[NSArray objectAtIndex:].
The
Well,
I just made new bugreport #5955452 to enhance docs sets with more
sample code inside of method descriptions. I took NSEnumerator's
nextObject method as a sample how to do it the right way..
On Thu, May 22, 2008 at 12:37 AM, Peter Duniho [EMAIL PROTECTED] wrote:
It's true, the phrase riff-raff wasn't actually used. But it's the
essence of what was written.
I'm not reading between the lines. People are explicitly stating the
opinions I've described.
I don't think you
On May 21, 2008, at 9:58 PM, Andy Lee wrote:
There's already an inherent lower bound on the barrier to entry for
Cocoa. You have to understand certain fundamentals -- some
conceptual, some procedural. If you don't have those fundamentals,
you'll never make Cocoa work. There is also a
On 22 May 2008, at 4:55, David Casseres wrote:
That's a really good idea, your wiki-that's-more-than-a-wiki.
You're in charge!
8^{)
Ha Ha
But just as a matter of interest, how would one set about talking to
apple about such a thing?
I would guess one would need first to demonstrate some
Perhaps a better way of doing this would be a web or WebKit app with
two panes. One that shows the Apple docs at Apple's site, and the
other pane points to a page at a non-Apple wiki site that corresponds
to the currently displayed Apple site.
That would ensure that the Apple content stays
On May 22, 2008, at 7:46 AM, Jeff LaMarche wrote:
On May 21, 2008, at 9:58 PM, Andy Lee wrote:
There's already an inherent lower bound on the barrier to entry for
Cocoa. You have to understand certain fundamentals -- some
conceptual, some procedural. If you don't have those fundamentals,
On May 22, 2008, at 12:17 PM, Sherm Pendley wrote:
On Thu, May 22, 2008 at 12:02 PM, Andy Lee [EMAIL PROTECTED] wrote:
The vast majority of this thread, if not all of it, has been about
people struggling to understand the frameworks as they are.
We're talking subjective impressions here, so
On Thu, May 22, 2008 at 5:02 PM, Andy Lee [EMAIL PROTECTED] wrote:
I think we have a disconnect as to what you meant by lowering the barriers
-- hence my reference to that particular phrase.
I'd like to point out that the barrier to which my post referred to
was that of *commitment* to the
On May 22, 2008, at 12:39 PM, Jeff LaMarche wrote:
On May 22, 2008, at 12:02 PM, Andy Lee wrote:
Most of this thread, if not all, has NOT been about people failing
to read the HIG.
I did not mention the HIG on purpose. Although I suggest reading it,
consistency goes far beyond conforming
On May 22, 2008, at 1:23 PM, Hamish Allan wrote:
On Thu, May 22, 2008 at 5:02 PM, Andy Lee [EMAIL PROTECTED] wrote:
I think we have a disconnect as to what you meant by lowering the
barriers
-- hence my reference to that particular phrase.
I'd like to point out that the barrier to which my
On 22.05.2008, at 00:58, Rua Haszard Morris wrote:
1 Apple's docs, particularly in relation to Objective-C Cocoa,
have some room for improvement:
- e.g. navigation (can't go back to list of methods after clicking
a method name hyperlink for example)
- lack of and generally un-useful
On May 22, 2008, at 6:23 AM, Robert Cerny wrote:
Well,
I just made new bugreport #5955452 to enhance docs sets with more
sample code inside of method descriptions. I took NSEnumerator's
nextObject method as a sample how to do it the right way..
On May 22, 2008, at 10:39 AM, Julius Guzy wrote:
On 22 May 2008, at 4:55, David Casseres wrote:
That's a really good idea, your wiki-that's-more-than-a-wiki.
You're in charge!
8^{)
Ha Ha
But just as a matter of interest, how would one set about talking to
apple about such a thing?
I
On May 22, 2008, at 11:15 AM, Jonathan Hendry wrote:
Perhaps a better way of doing this would be a web or WebKit app with
two panes. One that shows the Apple docs at Apple's site, and the
other pane points to a page at a non-Apple wiki site that
corresponds to the currently displayed
On May 20, 2008, at 10:50 PM, Steve Weller wrote:
However you slice it and whatever your personal experience, I
believe that what we are experiencing with the docs are the early
symptoms of massive scaling of the problem vs. insufficient scaling
of the resources to tackle it. If anyone
On May 20, 2008, at 9:52 PM, Peter Duniho wrote:
Each language varies a bit, of course. But in the other popular
languages that I know reasonably well -- C++, C#, Java -- a subclass
does not have the ability to touch any part of the base
implementation that is not specifically exposed by
On May 21, 2008, at 12:49 AM, Jeff LaMarche wrote:
This is really a fascinating discussion and, unfortunately, a time
consuming one =)
I can't help but feel that we have two identifiable camps forming,
and I'm not sure I like that. Though a range of opinions have been
stated, it seems
On May 21, 2008, at 12:01 AM, j o a r wrote:
On May 20, 2008, at 9:52 PM, Peter Duniho wrote:
The goal is not for every language to mimic C++/C#/Java.
I never said that was the goal.
Different languages serves different purposes and there is no
single best language.
I agree. So?
[...]
First off: all well said! +1
...a few comments though. (Will this thread ever gonna stop? ;) )
First, how much are you paying for the documentation? How much did
you pay for the IDE? I mean, I'd love everything to be perfect for
everybody, but let's be realistic here. Apple doesn't derive
On Wed, May 21, 2008 at 8:49 AM, Peter Duniho [EMAIL PROTECTED] wrote:
And again: it's not that I'm on a crusade to have Objective-C changed, or to
have Cocoa made fully accessible via some other language. I just want
people to have some empathy for what at least some of us go through upon
On May 21, 2008, at 12:49 AM, Peter Duniho wrote:
I have already acknowledged that opinions vary. You, being among
the regular contributors to this mailing list, I fully expect to
think that Objective-C find a pragmatic sweet spot. Anything else
would surprise me.
There are a lot of
On May 21, 2008, at 3:06 AM, Scott Anguish wrote:
I'm not sure that how much is being 'paid' for the documentation is
a valid metric.
I believe (not speaking for the company of course) that both of
these areas are viewed as investments.
No, you're right, it's not a good metric, and I
On May 21, 2008, at 4:31 AM, Torsten Curdt wrote:
Well, they are free to open source XCode and have other people help.
Look at Eclipse.
You can suggest it to them, but I wouldn't hold your breath. :)
Probably shouldn't open up that argument in this thread.
Paying for documentation is a
Well, they are free to open source XCode and have other people
help. Look at Eclipse.
You can suggest it to them, but I wouldn't hold your breath. :)
Probably shouldn't open up that argument in this thread.
No ...I don't hold my breath :)
I think even for the documentation user generated
I think face-to-face is an important part to overcome the
obstacles. And this will become easier the more popular it gets.
Amen. I can't tell you how much I sometimes hate having moved away
from the SF Bay Area where there are many Cocoa Programmers, and
there are NSCoder nights, and
On 2008/05/21, at 13:59, Jean-Daniel Dupas wrote:
I think face-to-face is an important part to overcome the
obstacles. And this will become easier the more popular it gets.
Amen. I can't tell you how much I sometimes hate having moved away
from the SF Bay Area where there are many
As I remember it, about 20% of DECs revenue stream came from
documentation, not software or hardware.
The English Department of my university produced a steady stream of
technical writers who went to DEC.
As you might imagine I come from a FORTRAN background followed by
procedural Pascal.
Scott,
Thank you for taking time to reply. You must be getting pretty tired
of all this. Worse, this is not a documentation issue, it's an Apple
issue.
On May 20, 2008, at 11:51 PM, Scott Anguish wrote:
[helpful pointers and other parts snipped]
Ultimately, learning is a very
On May 21, 2008, at 9:45 AM, Steve Weller wrote:
Don't you see how different the learning experience is for 100,000
iPhone developers in 2008 vs. a few hundred Next developers twenty
years ago? And the differences in motivation? And background? And
sponsorship?
Scott, you *are* doing
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
Am 21.05.2008 um 15:12 Uhr schrieb Joseph Ayers:
I'll cite one example. I've been spending two weeks trying to get a
table to reloadData to a multi column NSTableView that
I created programmatically. Creating the table view was
straightforward. Getting it to populate is yet another matter.
Sorry for the caps, not sure how else to try and get everyone's
attention.
This thread has been interesting and useful. In order to continue to
keep it so (if there is even anything left to be said) please keep in
mind the following.
- Don't debate the languages involved. Objective-C is
On May 21, 2008, at 12:52 AM, Peter Duniho wrote:
Cocoa restrains class extension _much_ less than any of these other
languages, and in turn has a _much_ higher degree of hazard.
I think you're overestimating the hazard. Or, at least, the risk that
it can be encountered accidentally.
On May 21, 2008, at 1:42 AM, Hamish Allan wrote:
I'm getting lost as to whether your main objection is about Apple not
providing anything other than Objective-C / Cocoa to develop apps on
the Mac, or whether it's just that you think their documentation could
be improved.
Sorry, that's fair.
On May 21, 2008, at 1:30 PM, Peter Duniho wrote:
My _main_ objection is how newcomers to Mac development are
treated. Please, when someone new to the current Mac development
environment brings up one or more of these points, don't say well,
you're too inexperienced to see why
On Wed, May 21, 2008 at 1:30 PM, Peter Duniho [EMAIL PROTECTED] wrote:
My _main_ objection is how newcomers to Mac development are treated.
Please, when someone new to the current Mac development environment brings
up one or more of these points, don't say well, you're too inexperienced to
On Wed, May 21, 2008 at 12:14 PM, Jeff LaMarche [EMAIL PROTECTED] wrote:
On May 21, 2008, at 1:30 PM, Peter Duniho wrote:
My _main_ objection is how newcomers to Mac development are treated.
Please, when someone new to the current Mac development environment brings
up one or more of these
I don't believe Peter Duniho's barking up the wrong tree - he sees
room for improvement, and wants to discuss what to do to make it
happen. I.e. he appears to care about making the platform better
(probably something we all share)...
These are the main valid issues from my point of view:
On 21 May 2008, at 23:58, Rua Haszard Morris wrote:
I don't believe Peter Duniho's barking up the wrong tree - he sees
room for improvement, and wants to discuss what to do to make it
happen. I.e. he appears to care about making the platform better
(probably something we all share)...
On Wed, May 21, 2008 at 6:58 PM, Rua Haszard Morris
[EMAIL PROTECTED] wrote:
2 Cocoa requires you when learning to implement things by clicking and
dragging, which makes learning harder for some people (this is a real
annoyance to me, why can we not see/edit these connections in a text file?
I'm curious:
On May 21, 2008, at 3:58 PM, Rua Haszard Morris wrote:
- lack of and generally un-useful sample code
There is quite a lot of sample code at developer.apple.com. Did you
know? What would make it more useful?
- too much cocoa is wonderful vs. not enough dry detail
So
Date: Wed, 21 May 2008 15:14:24 -0400
From: Jeff LaMarche [EMAIL PROTECTED]
Pete - you complain that people should treat newcomers better, yet
here you are characterizing what many of us have said in a blatantly
antagonistic way. Riff-raff? We like that it's keeping you out?
Nobody said any such
On May 21, 2008, at 12:27 PM, Sherm Pendley wrote:
On Wed, May 21, 2008 at 1:30 PM, Peter Duniho [EMAIL PROTECTED]
wrote:
My _main_ objection is how newcomers to Mac development are
treated. Please, when someone new to the current Mac development
environment brings up one or more of
2 Cocoa requires you when learning to implement things by clicking
and
dragging, which makes learning harder for some people (this is a real
annoyance to me, why can we not see/edit these connections in a
text file?
why is there so much other crap in the nib xml? etc).
The fact that you
On May 21, 2008, at 7:37 PM, Peter Duniho wrote:
It's true, the phrase riff-raff wasn't actually used. But it's
the essence of what was written.
I don't know why it is you guys didn't notice those particular
statements, and I agree that they aren't representative of the bulk
of the
Date: Wed, 21 May 2008 16:33:29 -0700
From: William Turner [EMAIL PROTECTED]
- too much cocoa is wonderful vs. not enough dry detail
So several people have alleged. Looking at the documentation, I'm not
finding anything that seems to qualify as hype. Could you provide some
links?
For what
On May 21, 2008, at 6:58 PM, Rua Haszard Morris wrote:
I don't believe Peter Duniho's barking up the wrong tree - he sees
room for improvement, and wants to discuss what to do to make it
happen. I.e. he appears to care about making the platform better
(probably something we all share)...
On May 21, 2008, at 8:01 PM, Jeff LaMarche wrote:
Hamish was making a general statement (and stating his opinion)
about what he saw as the likely outcome of lowering the barriers to
entry.
Jeff, given the many good points you've made that made perfect sense
to me, the phrase lowering the
I should clarify my reason for that statement, since it has been
somewhat misconstrued. I think we can all see that the software
situation on Windows (let's name names) is undesirable from the point
of view of the average user. It may be desirable from certain other
perspectives but that's
[deleted]
But there is no clear specific conceptual reason (that I know of) why
a list of these connections could not be made more user-editable.
What's more, this makes documenting simple code examples much harder,
as the drags all need to be documented in a necessarily less-rigourous
way (and
That's a really good idea, your wiki-that's-more-than-a-wiki.
You're in charge!
8^{)
On May 19, 2008, at 5:31 AM, Julius Guzy wrote:
Well I never thought I would cause this much discussion.
I have tried but do not have the time needed to reply to all.
I might still but work must take
Date: Tue, 20 May 2008 04:26:08 +0200
From: Andreas Mayer [EMAIL PROTECTED]
Am 19.05.2008 um 22:36 Uhr schrieb Peter Duniho:
But not the sort of compelling we really need the language to be
this way otherwise it just doesn't work example I was hoping for.
There is no such example. As was
Date: Mon, 19 May 2008 19:18:30 -0400
From: Andy Lee [EMAIL PROTECTED]
[...] When you are accessing only the public API for a class, C#'s
extension methods provide the same sort of syntax, but via static
methods that the compiler handles so as to make them look like they
are part of the
On May 20, 2008, at 1:07 AM, Peter Duniho wrote:
But personally, it makes me nervous to have a language that allows
the implementation of a class to change according to other code not
related to the class. It's one thing if you're just adding a method
that you want to use somewhere else.
Am 20.05.2008 um 09:47 Uhr schrieb Peter Duniho:
It's Turing. As in Alan Turing.
Thank you very much for pointing out that typo. -.-
Just because two languages are Turing-Complete, that doesn't mean
that they will have equivalent implementations.
I didn't say that. You talked about not
Date: Tue, 20 May 2008 01:34:32 -0700
From: G?rard Iglesias [EMAIL PROTECTED]
[...]
It is a question of intellectual curiosity I believe, maybe you are
too old and tired to take new risk and have more fun ?
Yup, that must be it. I'm too old to get Objective-C. After all,
it's technology
It is a question of intellectual curiosity I believe, maybe you are
too old and tired to take new risk and have more fun ?
Yup, that must be it. I'm too old to get Objective-C. After all,
it's technology that's only 20 years old. It's really for those
young whipper-snappers, who are
I wanted to throw in another set of experiences and opinions, as
someone who has recently been (re)learning Cocoa for a new application.
Background... programming since mid-80's, MSc in HCI/CSCW, worked on a
number of significant Mac programs off and on since the phone book
edition of
Am 20.05.2008 um 19:54 schrieb Erik Buck:
I agree completely with Mark Roseman's analysis:
I'm not quite with Mark and Erik.
1) Too many chioces
The world the software is developed for is complex to such a degree,
that we need many choices. But don't torture yourself, and apply
On 21 May 2008, at 2:41 am, Mark Roseman wrote:
4. Doesn't support everything. I'm being slightly facetious here,
but what I really mean is that there are some things you might think
are (should be) easy, that you have to create for yourself. If
anyone has used Tk, you know about its
On Tue, May 20, 2008 at 4:07 PM, Peter Duniho [EMAIL PROTECTED] wrote:
But personally, it makes me nervous to have a language that allows the
implementation of a class to change according to other code not related to
the class. It's one thing if you're just adding a method that you want to
However you slice it and whatever your personal experience, I believe
that what we are experiencing with the docs are the early symptoms of
massive scaling of the problem vs. insufficient scaling of the
resources to tackle it. If anyone can fix this, it is Apple.
If you care to invest the
This is really a fascinating discussion and, unfortunately, a time
consuming one =)
I can't help but feel that we have two identifiable camps forming, and
I'm not sure I like that. Though a range of opinions have been stated,
it seems that most of us can be readily identified as being on
Date: Wed, 21 May 2008 08:33:40 +0800
From: Michael Ash [EMAIL PROTECTED]
On Tue, May 20, 2008 at 4:07 PM, Peter Duniho [EMAIL PROTECTED]
wrote:
But personally, it makes me nervous to have a language that allows
the
implementation of a class to change according to other code not
related to
For clipping tasks like this, NSBezierPath is a very poor cousin to
Apple's old technology for this - Regions. With regions one could
trivially obtain union, intersection, difference and xor of complex
shapes using the built-in APIs. Neither NSBezierPath nor the
underlying Quartz routines
Is there any reason to use the cast on cbbox, instead of using
NSRectFromCGRect(cbbox), which does the same thing but wraps it up
nicely in an easy-to-read fashion?
From the docs:
NSRectFromCGRect
Returns an NSRect typecast from a CGRect.
NSRect NSRectFromCGRect(CGRect cgrect) { return
Yes, it's not available pre 10.5
G.
On 19 May 2008, at 4:31 pm, Andrew Merenbach wrote:
Is there any reason to use the cast on cbbox, instead of using
NSRectFromCGRect(cbbox)
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not
FROM : Peter Duniho
DATE : Mon May 19 07:03:25 2008
[deleted]
Real people are having real problems getting into Cocoa. I don't see
the kind of repeated commentary about poor documentation and
difficult APIs in the C#/.NET forums or Java forums. It comes up
once in a blue moon, but not with the
It's an inline fonction, so code compiled using this function will
properly work on pre 10.5 versions of the OS.
Le 19 mai 08 à 08:34, Graham Cox a écrit :
Yes, it's not available pre 10.5
G.
On 19 May 2008, at 4:31 pm, Andrew Merenbach wrote:
Is there any reason to use the cast on
On May 19, 2008, at 12:03 AM, Peter Duniho wrote:
From: ben syverson [EMAIL PROTECTED]
This is going to sound bitchy, but it's hard for me to have any
sympathy for vague complaints about the docs or the usability of
Cocoa.
That does sound bitchy. I mean, it's fair enough to say that people
Ah, OK, I'd missed that.
But it raises another question I've been vaguely meaning to ask the
list, but which is pretty minor, so I haven't so far bothered:
If I declare a C function as static inline inside a .m file (just to
be clear, it's C function, not an Obj-C method) does it get
I would be really surpise if it is not. (and the Show assembly Xcode
command tell me that I'm right). I think their is no garantee that the
function will be inlined, as the inline keyword is just a compiler's
hint, but the NS_INLINE macros is defined like this:
static __inline__
On May 19, 2008, at 1:19 AM, ben syverson wrote:
On May 19, 2008, at 12:03 AM, Peter Duniho wrote:
From: ben syverson [EMAIL PROTECTED]
This is going to sound bitchy, but it's hard for me to have any
sympathy for vague complaints about the docs or the usability of
Cocoa.
That does sound
Date: Mon, 19 May 2008 02:35:12 -0400
From: Erik Buck [EMAIL PROTECTED]
[...] It comes up
once in a blue moon, but not with the reliability I've seen here, nor
is there nearly the kind of practiced, organized defense seen here
(which again suggests a certain regularity to the complaints).
On 19 May 2008, at 5:21, : Nathan Kinsinger
[EMAIL PROTECTED] wrote
Subject: Re: Cocoa et al as HCI usability problem
I don't have a CS degree and would qualify, as one poster deridingly
called early mac programmers, as a hobbyist. I have approached
learning cocoa seriously and actually
On May 19, 2008, at 3:26 AM, Jean-Daniel Dupas wrote:
That'd be great for the Mac, but not so great for the Cocoa
evangelists. It's hard to understand the neglect Java has seen on
the Mac, except as a way to try to steer more people towards Cocoa.
Cocoa is a framework, Java a language.
Actually, I don't understand why an RTFM kind of answer is perceived
as rude. I'm really happy when I get an RTFM *with a link* to the
appropriate document.
Also, I often just don't answer at all, since an RTFM may not be
well received and I don't have the time to write a more elaborate
That'd be great for the Mac, but not so great for the Cocoa
evangelists. It's hard to understand the neglect Java has seen on
the Mac, except as a way to try to steer more people towards Cocoa.
Cocoa is a framework, Java a language.
The comparison is not as wrong as you say. Java is
On Mon, May 19, 2008 at 6:10 PM, Peter Duniho [EMAIL PROTECTED] wrote:
It should be clear from the volume of push-back that
not all is well in Cocoa-Land, even if the complaints are sometimes vague.
This is absurd. Every programming system I have ever encountered that
rises above the level of
Well I never thought I would cause this much discussion.
I have tried but do not have the time needed to reply to all.
I might still but work must take precedence.
There have been a number of people who suggested I give specific
instances of documentation failure.
I agree it would be useful
1 - 100 of 174 matches
Mail list logo
