Re: Thoughts on Cocoa source code
Re: Thoughts on Cocoa source code
- Subject: Re: Thoughts on Cocoa source code
- From: Turtle Creek Software via Cocoa-dev <email@hidden>
- Date: Fri, 11 Oct 2019 10:59:19 -0400
I checked the GNUstep project, and it does seem decently clear and
well-commented. If Apple made it possible to see and step through some of
the basic Cocoa classes, that would be a good starting point. The hard
parts for us were NSView and its subclasses (especially NSTableView &
associates, NSTabView and NSComboBox in that order). The whole constraint
system. ARC. Getting nibs to work properly when one little setting was
wrong.
In general, we weren't curious at all about the inner implementations of
Cocoa. The problems that held us back were in getting it to work for our
app. Something is drawing solid black. Why?
Rather than crown jewels, I think the best analogy for Cocoa should be an
excavator or a backhoe. Some people run one full-time, but some pick it up
from the rental place, and just want to get some stuff done over a
weekend. What's the best way to make it productive, quickly? The
long-time operators on this list know all the tricks, but Cocoa should also
allow the rest of us to build apps relatively quickly. In our case, that
means less than 3 years.
Casey McDermott
TurtleSoft.com
On Fri, Oct 11, 2019 at 9:47 AM Saagar Jha <email@hidden> wrote:
> I’m sure much of the Cocoa code is quite old, but it’s mostly all
> Objective-C. If you’re curious how it might work, but don’t want to use a
> disassembler, the GNUstep project has a somewhat decent (though
> incomplete) reimplementation <https://github.com/gnustep/libs-gui> that
> you can look at.
>
> Saagar Jha
>
> On Oct 11, 2019, at 06:18, Turtle Creek Software via Cocoa-dev <
> email@hidden> wrote:
>
> If you combine otool, classdump and Hopper Disassembler, you can find
>
> how some Cocoa methods are working in any Obj-C executable pretty easily.
>
> Here's the thing. We started out as construction folks who learned Excel.
> Then HyperTalk. Then C++. As a business, our main strength is knowing the
> construction business, and how to talk to folks in it. Our time is best
> spent solving business-related problems. Along the way we have learned
> many programming and human-interface skills, but the less time we need to
> spend on that, the better.
>
> If a programming environment requires zombies, disassemblers and other BS
> just to make it work, that is a big problem. It's too much extra overhead.
> Our company can't afford it.
>
> I'd agree that the documentation for Cocoa is deficient.
>
> CodeWarrior included a huge Inside PowerPlant book, modeled on our
> well-worn copies of Inside Macintosh. But we rarely used it. Having
> clearly-written source code and good comments is probably the best form of
> documentation. Being able to step through it easily and see it in action is
> a huge plus.
>
> I suspect that Cocoa source code is ancient C that is badly in need of a
> refactoring. Making it open, understandable and self-documenting would be a
> great way to improve it. Based on our refactoring experiences, it would
> end up being faster, safer and less buggy.
>
> There probably are some parts of Cocoa that are extremely proprietary- but
> even then, plain old patents are better than hiding the code, as a way to
> protect the jewels. Competitors can always disassemble, as you suggest.
>
> Speaking of early-Aughties history. We hired some subs to write the Windows
> version of our app. They took a short-cut and used QuickTime DLLs, though a
> lot still needed native MFC. Metrowerks offered to buy it from us so they
> could make PowerPlant cross-platform. Sadly, before we finished
> negotiations, Motorola did a re-org and our contact disappeared. MW soon
> sold off their Intel compiler, just in time for Mac to switch chips. The
> rest is history.
>
> Casey McDermott
> TurtleSoft.com
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> 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:
>
> This email sent to email@hidden
>
>
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden