Re: Thoughts on Cocoa source code
Re: Thoughts on Cocoa source code
- Subject: Re: Thoughts on Cocoa source code
- From: "Gary L. Wade via Cocoa-dev" <email@hidden>
- Date: Fri, 11 Oct 2019 08:31:17 -0700
I’m one of the few on the list who has experienced every growing pain you’ve
mentioned from 680x0 Macintosh now up to SwiftUI, and not only supporting a US
English environment but even RTL UI (Arabic and Hebrew scripts) mixed with LTR
languages across every current platform, and I will admit it’s hard.
The way I found Cocoa development to be easier was to change my way of
thinking. In almost every case, it was better to completely separate the
business logic from the UI handling logic. In other frameworks, the paradigm is
to subclass a view; in Cocoa, everything is built to be as MVC as possible. Of
course, there are exceptions, but if you find yourself wanting to subclass a
view, think hard and look around—it might be better to compose a view of other
views or there is a better, more Cocoa way of doing it. For Mac and SwiftUI,
you can even write “no” code to do some things with bindings.
It’s possible to do a progressive port, but in many cases, you might find it
easier to re-model (pun intended) your design.
True, the classes you mentioned are difficult, but I’ve seen many of their
difficulties in thinking of them as a 1-1 replacement for comparable
affordances in other frameworks or platforms.
Definitely use your tech support incidents, and if you find something not
behaving as defined or not defined well, submit feedback to Apple and feel free
to post those here. There’s also a site where you can voluntarily add your
feedback requests to Apple, but I don’t recall it right now.
--
Gary L. Wade
http://www.garywade.com/
> On Oct 11, 2019, at 8:00 AM, Turtle Creek Software via Cocoa-dev
> <email@hidden> wrote:
>
> 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