Re: Thoughts on Cocoa
Hi Jens, > On 3 Oct 2019, at 20:04, Jens Alfke via Cocoa-dev > wrote: > > The people I hear complaining about this are those who, like you, didn't move > to Cocoa. Carbon was a _temporary_ transition API*. It wasn’t clear to us (outside Apple) that Carbon was a temporary API until 2007, when Apple suddenly abandoned 64-bit Carbon. That might have been a good decision from Apple’s perspective, but we found it was extremely difficult to convert a large Carbon (C++) program into a Cocoa (C++ / ObjC) program. We attempted to do this (starting in 2007) and we failed. There were various reasons for this failure - but in the end (starting in 2017) we decided to do a complete rewrite using Cocoa and Swift. I know there are large companies that successfully moved from Carbon to Cocoa, including Apple itself. iTunes and the Finder became Cocoa programs at some point. But I don’t think it was easy for small companies with large/complex programs. Personally, I think that Cocoa is a much better framework than Carbon ever was. But I wish that Apple had made it easier to transition from Carbon to Cocoa. Jeremy ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Thoughts on Cocoa
> On 4 Oct 2019, at 11:43, Dragan Milić via Cocoa-dev > wrote: > >> pet 04.10. 2019., at 11.51, Jeremy Hughes via Cocoa-dev wrote: >> >> It wasn’t clear to us (outside Apple) that Carbon was a temporary API until >> 2007, when Apple suddenly abandoned 64-bit Carbon. > > I don’t agree. Maybe it was clear to you, but it wasn’t clear to us. The company I work for sent developers to WWDC, and the message they came back with was that Carbon was a serious alternative to Cocoa. Of course, Apple changed its plans several times during this period, but the abandonment of 64-bit Carbon - after it had already been developed - was sudden and unexpected (to us). It’s ancient history now. I wish Apple had given a clearer message and provided an easier transition. Carbon provided an easy way to transition from classic macOS, but there wasn’t an easy way to transition from Carbon to Cocoa. Jeremy ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Need for Swift
Maybe it’s also worth noting that WebKit (the browser engine used by Safari) is written in C++ Safari’s UI is probably written in Obj-C(++) or a mixture of Obj-C(++) and Swift. Jeremy ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Need for Swift
> On 15 Oct 2019, at 18:27, Turtle Creek Software via Cocoa-dev > wrote: > > MVC is an excellent design paradigm. The M and V layers were no problem at > all to set up. The C started out easy, but ended up being a big problem. > Quite a bit of the business logic is not just data, but fancy stuff that > happens with the GUI. Fields that switch between % and $, table cells that > change other table cells, etc. There is a lot of code in our C++ > RecordViewer classes to make that happen, and it didn't integrate easily > with NSWindowControllers or NSViewControllers. It often was faster to just > redo the logic in Cocoa. That took a lot of time. Much more rewriting than > expected. If the RecordViewer is a controller of some kind, could you not add it to a view controller, and let the view controller (an ObjC++ subclass of NSViewController) call the RecordViewer to make these changes? It sounds like you actually made quite a bit of progress if you’ve already rewritten the View (V) layers, and the Model (M) layer is separate. Jeremy ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
