Re: Spoiled by Java IDEs
Re: Spoiled by Java IDEs
- Subject: Re: Spoiled by Java IDEs
- From: Jeffrey Oleander <email@hidden>
- Date: Fri, 18 Jul 2008 09:34:19 -0700 (PDT)
> On Thu, 2008/07/17, Wade Tregaskis <email@hidden> wrote:
> From: Wade Tregaskis <email@hidden>
> Subject: Re: Spoiled by Java IDEs
> To: "James Boutcher" <email@hidden>
> Cc: email@hidden
> Date: Thursday, 2008 July 17, 21:47
>> 1) When defining a new method in a header file, it
>> would really be nice if I could click on the
>> method name or something and say "Generate
>> skeleton implementation in .m file"
Yes, you should at least be able to get a limited
set of constructors, destructors, and a single
group of setter/ accessor/ copier skeletons as
appropriate for the language.
>> 2) If I create a class which inherits from some
>> other class (which I guess is every class, eh),
>> I'd love to be able to pick something from a
>> menu like "Override Methods of Superclass"...
>> I'm a newbie, so how in the heck am I supposed
>> to know that my custom NSView subclass has a
>> method called
>> "(void)displayRectIgnoringOpacity: (NSRect)rect"
>> that I can override?
>
> There are probably hundreds of methods in the
> superclasses, for any real world class... you
> want it to override all of them?
I think what he was asking for was a list from
which to choose, so that he's got the methods
right there and so it generates an appropriate
skeleton of the chosen method in his new
derived class.
I'd settle for a decent example in the docs of
either the currrent version of a method (where
they're not virtual) or an over-ride that actually
does something useful, so that I can have some
insight into what the class designers had in mind,
which the docs carefully avoid conveying.
What especially drives me nuts (next to the "We're
supplying this great feature for you in Cocoa. Just
invoke these skeletons that don't do anything and
write your own call-back that does all the work
which you will need to do, but which we will carefully
avoid describing in even a generally useful say."
At least the old SDKs gave us a core of something
minimally useful that we could adapt), are things
like the drawWhatever methods that we're told to
"override to draw your" stuff, and the ones named
drawThatother that don't really draw anything at
all, but merely prepare to prepare to prepare to
draw, because heaven forbid a developer actually
be able to work with the systems and tune his apps
and be able to actually have something done on
the display at that time for the user to see in
sequence and the user be able to reasonably
interact with.
I just read a great doc, a blast from the past,
James E. Thornton _Design of a Computer: The Control
Data 6600_. Some of the circuit diagrams are a
little lacking in detail or the legend/key a bit
skimpy, but it's much clearer than the hand-waving,
incomplete, sleight of hand indirection mush I've
seen for OS X, Cocoa, Xcode, etc. over the last
7 years. And yes, I've submitted a lot of both
general and detailed doc evaluation forms.
[OK Variants of that rant break out periodically
but I'd really like to see some improvements or
I wouldn't be submitting all those forms, and
the economy has got many of the folks I interact
with via the net on edge these last few days.
Further deponent saith not.]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden