Re: troubling article
Re: troubling article
- Subject: Re: troubling article
- From: Jeff <email@hidden>
- Date: Tue, 10 Jun 2003 23:09:36 -0600
This was an excellent set of comments. I'm sure resources like the ones
you suggest would be welcomed, and it sounds eminently doable. I wonder
what could be done in the Cocoa user community to provide the PB/IB
tools for this functionality. Perhaps a nice open-source effort to
enhance PB/IB could make all the difference. Apple has done a great job
with what resources they have, but I'm sure they also have time and
resource constraints. There's a (very) small number of helper tools for
PB, but it would be welcomed to see much more of this. Maybe after the
WWDC, if the dev tools are updated, would be a good time to try to
provide this kind of functionality. I get the impression that PB is
fairly open for such expansion, though I've not done anything like
that. Would this seem worth while to others as well? (Is there
something already underway that I'm unaware of?)
-Jeff
On Tuesday, June 10, 2003, at 09:43 PM, Andy Satori wrote:
That said, he's right. Windows development tools remain years ahead
of Project Builder and CodeWarrior in terms of dumbing down the
developer requirements. In none of todays commercial development
environments for Windows does the developer need an API or command
reference, the tools do the work. For example, in Windows, I want to
solve a problem I recently had, GetUser(). In any of the languages,
with the exception of VB (which doesn't have that call directly
implemented), typing 'GetUser(' would prompt me with a tool tip
containing the parameters and types from the Windows.h definitions.
In the Cocoa world you have to dig through poorly indexed, HTML or PDF
materials.
The situation with object methods and parameters is even worse. In
the Windows environments, if I declare an object as 'Variant', the
IDE's will make an effort to determine the object type by how it's
instantiated, if it fails, it doesn't work. If however, the object is
declared by type, typing 'objectVariableName.' or
'objectVariableName->' in the C++ world would give me a type specific
list of methods and properties, to pick from. '[objectVariableName '
could, and in my opinion, should, do the same type of thing. If you
declare everything as 'id' then it's probably going to fail, and
that's your prerogative, me, I'm going to strongly type things and
happily fix the compiler errors because they are less likely to become
program errors.
Don't get me wrong, now that I've come to grips with the fundamental
shift in methodology, I like Cocoa, but I still find PRoject Builder
and CodeWarrior to be inferior tools to Delphi, C++ Builder, Visual
Studio, Visual Studio.NET, and even Visual Basic ( a language and
environment that I detest ).
I've spent most of my early Cocoa development efforts writing tools to
make my Cocoa life easier. I don't like writing boiler plate code, so
I've spent a couple of weeks building tools to let me create my object
and collections, complete with NSTableView support, from a GUI, and
let that generate the appropriate code. In the Windows world, these
'Wizards' and template derived code is part of the package, and is
more necessary, as the code for a basic COM object is 1000 lines of
boiler plate code, but the advantage of filling out 5 fields and
clicking Finish, to generate the code for a collection object that can
then be assigned to an NSTableView with one line of code is far
prefereable to the hand writing of 25 lines of Objective C.
Call me lazy, but Code Reuse only gets you so far. You still have to
have the foundation work to glue the OO elements together. But I
disagree with his conclusions, once you get over the 'hump' Cocoa
becomes a fun, and elegant framework that is more complete than it
first appears. That doesn't mean that I don't long for Code
Completion, and ToolTips with function parameters in them. I don't
find hunting HTML documentation in a Safari Tabbed set for that stuff
fun, when I'm spoiled to having so very handy.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.