Re: Xcode does seem hard on newbies(was Xcode release notes)
Re: Xcode does seem hard on newbies(was Xcode release notes)
- Subject: Re: Xcode does seem hard on newbies(was Xcode release notes)
- From: Brent Gulanowski <email@hidden>
- Date: Thu, 5 Aug 2004 13:13:03 -0400
On Thu, 5 Aug 2004 14:45:06 +0100, Theodore H. Smith <email@hidden> wrote:
> They should be integrated into one. In fact, there shouldn't need to be
> any manual editing of .h files or using filemerge when you add new
> outlets or actions to a class, it should all be done automatically.
Whether a particular software product is one or multiple executables
is beside the point. The two tools have almost nothing in common.
Integrating the IB code into Xcode would improve little or nothing.
Having a dedicated tool for a distinct task which uses (mostly)
distinct (completely file-based) data makes perfect sense. Transparent
file merging might be nice, but chances are it will only screw up your
nicely formatted header file, unless the developer is made to follow
rules of file content layout set by the tool, which will annoy a lot
of people.
>
> Also, the .h files should be automatically maintained from the .m
> files, that is, having to add stupid declarations is such a
> productivity and moral killer. Java doesn't need this. In fact, no
> language needs .h files. .h files are a product of linear thinking, a
> way of yesterday. Java is old enough as it is and it doesn't need .h
> files.
>
> To do without a .h file, the compiler must re-scan the document, but
> thats no problem. First it scans for classes/structs, and makes a list
> of them. Then it scans for functions/methods and properties, and makes
> a list of them. Then it scans the code, and compiles it, using the
> pre-made listing of classes, structs, functions methods and properties.
>
> That's 3 re-scan operations, but seriously it is incredibly fast to do
> string searching, I know because I've written many heavy duty string
> processing apps. gcc is slow because it isn't well designed, not
> because its got a hard task on it's plate.
>
*.h files are a requirement of the languages of C and Objective-C, in
that C requires forward declarations for all functions. This has
*nothing* to do with Xcode. Using headers removes the need to provide
your own forward declarations for extern functions and other global
symbols. The Java language is designed to not need method
declarations, and the compiler is such that it does multiple passes to
support this language feature. Headers are also useful for
documentation when you don't have *doc-generated (javadoc, headerdoc)
documentation.
That said, it is possible to arrange auto-generation of some parts of
headers if you have a more visually-oriented IDE, say one that permits
controlled access to parts of files (so you don't accidentally wreck
the auto-generated parts). Most C family language developers are not
keen on this as they have their personal styles and otherwise don't
trust tools which go to this extent. Me, I'd love more code
generation, especially header file generation. But you cannot change
the compiler until you change the language and C is not going to stop
requiring forward declarations any time soon. (Actually I'm guessing
on that one! It might be cool to dump that requirement but backwards
compatibility... I dunno.)
--
Brent Gulanowski
http://www.boredastronaut.com
_______________________________________________
xcode-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/xcode-users
Do not post admin requests to the list. They will be ignored.