This is the last bit of post-mortem from our failure with Cocoa. Thanks for
the patience of everyone who just wants to give or get tech answers here.
I was originally going to post about how modern C++ has far surpassed
Objective-C. Then suggest that Cocoa would work better if Obj-C were a
> On Nov 9, 2019, at 12:09 PM, Carl Hoefs via Cocoa-dev
> wrote:
>
> I'm trying to keep some older iOS code going, but I'm getting a deprecation
> warning on many UIView class methods:
>
> +beginAnimations:context:
> +setAnimationBeginsFromCurrentState:
> +setAnimationDuration:
>
>> Obj-C++ *is* a superset of C++, so I’m not sure what you’re wishing for.
In source files Obj-C++ works great. No complaints there. But headers and
method declarations are Obj-C, which is C plus its own additions.
That means no use of const. All pointers instead of & references. Both of
> That’s more open than Obj-C, because Apple never open-sourced Foundation.
AFAIK no Apple frameworks for Swift have been (or will be) open sourced
either.
> MSVC and .NET are both fully closed, as far as I’m aware.
.NET Core is fully open source:
https://github.com/dotnet/core
AFAIK Core is
If you wish to solve the problems you perceive to exist, you should join an
Objective-C/Objective-C++ email list or hire developers experienced in those
nuances.
--
Gary
> On Nov 11, 2019, at 10:47 AM, Turtle Creek Software via Cocoa-dev
> wrote:
>
>
>>
>>> Obj-C++ *is* a superset of C++,
> On Nov 11, 2019, at 9:28 AM, Pier Bover wrote:
>
> AFAIK no Apple frameworks for Swift have been (or will be) open sourced
> either.
Not higher-level ones, but the Swift standard libraries include the equivalent
of most of Foundation. Which is a big deal, because the lack of an
i too have this question
> On Nov 10, 2019, at 5:39 PM, Lars C. Hassing via Cocoa-dev
> wrote:
>
> I have developed two Cocoa apps, one launching the other helper app.
>
> If number two app crashes then macOS may ask the user if he wants to relaunch
> it,
> but it makes no sense launching it
> On Nov 11, 2019, at 6:15 AM, Turtle Creek Software via Cocoa-dev
> wrote:
>
> Then suggest that Cocoa would work better if Obj-C were a
> superset of C++ rather than plain C. Objective-C++ all the way down, not
> just in source files.
Obj-C++ is a superset of C++, so I’m not sure what
On Nov 11, 2019, at 9:46 AM, David Duncan wrote:
>
>> On Nov 9, 2019, at 12:09 PM, Carl Hoefs via Cocoa-dev
>> wrote:
>>
>> I'm trying to keep some older iOS code going, but I'm getting a deprecation
>> warning on many UIView class methods:
>>
>> +beginAnimations:context:
>>
I’m working on an Obj-C app that got started a bunch of years ago and thought
that I would start migrating some of the smaller pieces over to Swift.
Some existing Obj-C methods are of the form:
+ (nullable __kindof NSManagedObject) someFooThing;
Right now I have
class var
>
> Maybe I'm wrong, but we have experienced enough past pivots and
> bridge-burnings that another seems overdue.
>
Yes, I can understand that.
On the other hand, at least in the old days,
Microsoft kept all the old API's around for so many years
(for backwards compatibility),
including
> On Nov 11, 2019, at 10:46 AM, Turtle Creek Software
> wrote:
>
> That means no use of const. All pointers instead of & references. Both of
> those are good at turning run-time errors into compile-time. […] No
> public/private to manage access. Etc. It was like going back to the early
> On Nov 11, 2019, at 15:07 , Steve Christensen via Cocoa-dev
> wrote:
>
> Some existing Obj-C methods are of the form:
>
> + (nullable __kindof NSManagedObject) someFooThing;
>
> Right now I have
>
> class var someFooThing: NSManagedObject?
AFAIK, “__kindof” only affects the
On Nov 11, 2019, at 17:05 , Turtle Creek Software via Cocoa-dev
wrote:
>
> I didn't mean to start a language war, because it's not about C++ vs
> Objective-C or Swift.
I’ve been staying out of this, because you’ve seemed impervious (in the last
few weeks since this topic has been discussed)
You should be able to look at the header in Swift for your Objective-C class
and see what it should be.
> On Nov 11, 2019, at 8:06 PM, Steve Christensen via Cocoa-dev
> wrote:
>
> Yep, I understand what it does. I’m trying to get the same class-or-subclass
> behavior during compilation. I’d
I didn't mean to start a language war, because it's not about C++ vs
Objective-C or Swift. It's about whatever lets us create software that
runs on Macintosh and pays for the development cost. Right now, it only
makes sense to write an entire app in Objective-C or Swift if it's OK to
limit sales
On Mon, 11 Nov 2019 11:28:57 -0600, you wrote:
>> Thats more open than Obj-C, because Apple never open-sourced Foundation.
>
>AFAIK no Apple frameworks for Swift have been (or will be) open sourced
>either.
>
>> MSVC and .NET are both fully closed, as far as Im aware.
>
>.NET Core is fully open
There’s now a Swift equivalent (loosely): “some NSManagedObject”. It’s
sometimes referred to as a “reverse generic”, or “opaque type” because it hides
the actual type behind a larger class type or protocol. The evolution proposal
is here, if you want all the gory details:
On Nov 10, 2019, at 17:39 , Lars C. Hassing via Cocoa-dev
wrote:
>
> I believe data in "~/Library/Saved Application State" is being used for this,
> how can I programmatically in app two tell that restoration is not useful ?
>
> I’ve tried myMainWindow.restorable = NO.
The thing that’s
Yep, I understand what it does. I’m trying to get the same class-or-subclass
behavior during compilation. I’d looked at the stack overflow article earlier,
so I’ll check out the Swift forum to see what’s there. Thanks.
> On Nov 11, 2019, at 4:43 PM, Quincey Morris
> wrote:
>
>> On Nov 11,
20 matches
Mail list logo
