Re: other developer lists
Re: other developer lists
- Subject: Re: other developer lists
- From: Allan Odgaard via Cocoa-dev <email@hidden>
- Date: Fri, 15 Nov 2019 09:27:54 +0100
On 15 Nov 2019, at 0:53, Matthew Kozak via Cocoa-dev wrote:
Another reason why there's really no harm -if not some truly topical
good- in this kind of thread (even w/ some critiques/defenses)
bubbling up here now and again...
I don’t mind off-topic discussions, but the recent thread(s) have been
repetitive and borderline ranting.
For someone who spends 5-10 years planning a software release, it should
be obvious why Apple cannot commit resources to maintain a 100%
compatible port of Cocoa running under Windows. That they have iTunes
running on Windows says nothing about how “complete” the port is, as
iTunes makes very superficial use of Cocoa (it appears to be a WebView).
It is also nonsensical to suggest Objective-C be a superset of C++ as
the value provided by the former is the run-time and supporting
frameworks (NSObject) which rely on dynamic dispatch, interfaces, have
concepts like properties that can be observed, etc., none of which have
obvious counterparts in C++ and would thus have to be recreated like
done by BeOS and Qt, but in my opinion it is nowhere near as elegant as
what Apple/NeXT has done with Objective-C.
And as for what started the threads/rants: I bought my first PowerMac G4
18 years ago and it was clear to me back then, that Cocoa was the
preferred framework for any new development, and even back then, I could
use Objective-C++, although at very reduced compilation speeds.
That said, we could have interesting discussions about some of the
topics raised, for example one mail mentioned how C++ code was safer
than Objective-C code due to features such as const member functions,
default initialization of member data, etc., which invites a discussion
of best practices in Objective-C to achieve these things.
I also do understand the need to vent, there are definitely instances
where I fault Apple, for example when they deprecate API that has no
proper replacement, or when they deprecate API in favor of new API, only
to deprecate that new API 5 versions later, which gives you a bit of a
conundrum when you support the last 6+ major OS versions (should you
spend time upgrading to the “new” API knowing full well that it’s
only temporary). But it’s hard to claim ignorance about 32 bit *after*
the release of macOS 10.15.
_______________________________________________
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