Re: Swift -> Obj-C: return __kindof Something

[Quincey Morris via Cocoa-dev]

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:


https://github.com/apple/swift-evolution/blob/master/proposals/0244-opaque-result-types.md
 


The problem is, it was designed mainly for return types, and I’m not sure it’s 
entirely easy to use for a stored property. On top of that, it may not work 
with an optional base type.

Still, it might be worth looking into. Again, ask on the Swift forum for 
guidance. You’ll get good answers.

> On Nov 11, 2019, at 18:06 , Steve Christensen  wrote:
> 
> I’m trying to get the same class-or-subclass behavior during compilation.

___

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: Swift -> Obj-C: return __kindof Something

[Alex Zavatone via Cocoa-dev]

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 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, 2019, at 15:07 , Steve Christensen via Cocoa-dev 
>>> mailto:cocoa-dev@lists.apple.com>> 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 ability to assign one Obj-C class pointer 
>> to a variable of a different but compatible (kind of) type. It doesn’t 
>> change the actual type of the variable, nor does it (again AFAIK) change the 
>> ability to assign without errors in Swift. Also see here for some 
>> informative discussion:
>> 
>>  https://stackoverflow.com/questions/31399208/ios-kindof-nsarray 
>> 
>> 
>> I suggest you ask about this on forums.swift.org . 
>> If there’s an alternative, someone there will know.
> 
> ___
> 
> 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/zav%40mac.com
> 
> This email sent to z...@mac.com

___

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: Swift -> Obj-C: return __kindof Something

[Steve Christensen via Cocoa-dev]

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, 2019, at 15:07 , Steve Christensen via Cocoa-dev 
>> mailto:cocoa-dev@lists.apple.com>> 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 ability to assign one Obj-C class pointer 
> to a variable of a different but compatible (kind of) type. It doesn’t change 
> the actual type of the variable, nor does it (again AFAIK) change the ability 
> to assign without errors in Swift. Also see here for some informative 
> discussion:
> 
>   https://stackoverflow.com/questions/31399208/ios-kindof-nsarray 
> 
> 
> I suggest you ask about this on forums.swift.org . 
> If there’s an alternative, someone there will know.

___

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 Objective-C++

[Quincey Morris via Cocoa-dev]

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) to acknowledge any opinion other 
than your own. Now I’m just angry.

*Of course* you meant to start a language war. You said:

> 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
> superset of C++ rather than plain C.

Them’s fighting words — especially in a space like this that is inhabited by 
other highly opinionated people. If you don’t want to start a language war, 
stop posting here and go away.

The other thing you said:

> However, after consideration, it seems obvious that Apple will never do
> that. Instead, Objective-C and Cocoa will be deprecated soon, replaced by
> Swift and SwiftUI. That way there is just one shiny new closed system for
> all Apple hardware. So much simpler.

is both clueless and passive aggressive. Enough already.

___

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 Objective-C++

[Gerald Henriksen via Cocoa-dev]

On Mon, 11 Nov 2019 11:28:57 -0600, you wrote:

>> 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 only for servers but it's also coming to desktop apps:
>https://devblogs.microsoft.com/dotnet/net-core-3-and-support-for-windows-desktop-applications/

A suprisingly lot of Microsoft stuff is fully(*) open source these
days.

In addition to .Net Core(**) and its associated things (ASP.Net, WPF,
WinForms, ...) the new Terminal (including its new font), Visual
Studio Code, the Microsoft implementation of their STL (with the same
license as LLVM, deliberately chosen so sharing of code is posible),
and the latest (soon to be on GitHub) WinUI 3 which is currently alpha
and will be the new base for all their GUI stuff.  And they are
working to sort out the issue with proper Linux support for exFAT,
which has long been forbidden from the Linux kernel for patent
reasons.

.Net Core (soon .Net) is fully supported by Micrsoft on Windows,
macOS, and Linux - including some ARM support like the Raspberry Pi.
The Desktop stuff (WPF / Winforms) are add on modules for Windows only
but they are, through WinUI 3, contemplating the possibility of going
cross-platform given customer desire for it.

As for writing apps on Windows, the WPF / WinForms stuff is .Net only
so if you use C++ you need to interface to .Net for that.  However,
UWP (the Windows app store) and WinUI 3 both fully support C++ as well
as .Net so if you target either of those you don't need to use .Net at
all.

* - by fully, I mean not just the code but development is also done in
the open, frequently on GitHub.

** - .Net Core 3.x is the last of the Core line, the next major
release is simply .Net 5 and it also supercedes/replaces .Net
Framework that comes as part of Windows.
___

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 Objective-C++

[Turtle Creek Software via Cocoa-dev]

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 to Apple hardware.  That's no problem for iPhone apps, because
iOS has 57% share in the US.  Ditto for small Mac apps, because development
cost is small.

Unfortunately, software for any vertical or specialty market has to deal
with Mac market share. It's 20% overall, but only 2% or 3% for our niche,
and falling.  Probably 10% or less for businesses in general.  For most
apps, that means writing code in something other than Obj-C or Swift, with
minimal pain to connect it to a Mac GUI.  Then having it last long enough
for sales to repay the programming cost.  We couldn't accomplish that with
Cocoa as is.  Not with subs, nor with our own staff.  An easier connection
from C++ to Cocoa would have helped.

I'm really not eager to be working in MFC.  It has plenty of flaws, but at
least it's C++. We can ship a Windows update in a year or so. Then sell it
for another 10 or 20 years.  The only reason we need to update at all is
because the subs doing the Windows port cheated, and used QuickTime DLLs
for the Windows port.

Casey McDermott
TurtleSoft.com

On Mon, Nov 11, 2019 at 5:33 PM Jens Alfke  wrote:

>
>
> On Nov 11, 2019, at 10:46 AM, Turtle Creek Software <
> supp...@turtlesoft.com> 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
> 90s. Doing without features we learned to use the hard way.
>
>
> Well yes, Obj-C is not a very good C++, just as C++ isn't a very good
> Obj-C. And Haskell isn't a very good Ruby, and vice versa.
>
> I like C++ and use it daily, but I could write a litany of complaints
> about it compared to Obj-C and Swift — C++ has meager
> reflection/introspection, its collection and string APIs are horrendous, it
> has weak and awkward support for memory management, templates are a
> super-kludgy [SFINAE, OMG] way to implement generics,  it promotes writing
> unreadable code, etc.
>
> I'm not just joking here. Obj-C's dynamic nature is at the heart of a lot
> of Cocoa's powerful features like Interface Builder and KVO. Super-static
> languages like C++ don't work well for GUI development, IMHO, because they
> make it hard to compose high-level objects together.
>
> —Jens
>
___

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: Preventing app from being restored or saving info in "Saved Application State"

[Quincey Morris via Cocoa-dev]

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 relaunching your app isn’t state restoration, which is only 
about restoring state of and within windows.

If you’re talking about the “Reopen” button in the dialog that says your app 
crashed, I think that’s CrashReporter or some similar system component, and I’m 
not aware of any way of controlling the buttons it offers you.

So, the answer depends on what you’re asking.

— If you’re asking whether it’s possible to suppress the option to relaunch the 
crashed app, then no, I don’t believe there is.

— If you’re asking whether it’s possible for the app to suppress state 
restoration, if it’s launched via *any* unexpected mechanism, then I think 
you’re barking up the wrong tree. It’s just as wrong for your app to relaunch 
without state restoration as it to relaunch with state restoration. You would 
need to find a way of detecting that it was not launched by the correct base 
app (e.g. inter-process communication with that app, if it’s running), but I 
doubt there’s any built-in thing you could use for that either.

___

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: Swift -> Obj-C: return __kindof Something

[Quincey Morris via Cocoa-dev]

> 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 ability to assign one Obj-C class pointer to 
a variable of a different but compatible (kind of) type. It doesn’t change the 
actual type of the variable, nor does it (again AFAIK) change the ability to 
assign without errors in Swift. Also see here for some informative discussion:

https://stackoverflow.com/questions/31399208/ios-kindof-nsarray 


I suggest you ask about this on forums.swift.org . If 
there’s an alternative, someone there will know.

___

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

Swift -> Obj-C: return __kindof Something

[Steve Christensen via Cocoa-dev]

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 someFooThing: NSManagedObject?

but that generates a bunch of warnings saying there are incompatible pointer 
type, so Obj-C callers will need to cast the result to the specific subclass 
type:

SonOfFoo sonOfFoo = (SonOfFoo)SonOfFoo.someFooThing;

which was what the original method handled automagically.

I tried the generics route but Xcode complains because it will be used in 
Obj-C. Obviously I can just go through and cast to clean up the warnings, but 
if there’s a nicer solution then I’d rather go that route.

I’ve been searching around this afternoon trying to see if anyone else has run 
across this. I haven’t found anything yet, but I don’t know if that’s due to 
poor search terms, or because someone more experienced with the process would 
say, “well, of course you can’t do that”. Any help?

Thanks,
Steve

___

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 Objective-C++

[Jens Alfke via Cocoa-dev]

> 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 
> 90s. Doing without features we learned to use the hard way.

Well yes, Obj-C is not a very good C++, just as C++ isn't a very good Obj-C. 
And Haskell isn't a very good Ruby, and vice versa.

I like C++ and use it daily, but I could write a litany of complaints about it 
compared to Obj-C and Swift — C++ has meager reflection/introspection, its 
collection and string APIs are horrendous, it has weak and awkward support for 
memory management, templates are a super-kludgy [SFINAE, OMG] way to implement 
generics,  it promotes writing unreadable code, etc.

I'm not just joking here. Obj-C's dynamic nature is at the heart of a lot of 
Cocoa's powerful features like Interface Builder and KVO. Super-static 
languages like C++ don't work well for GUI development, IMHO, because they make 
it hard to compose high-level objects together.

—Jens
___

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: UIView block-based methods

[Carl Hoefs via Cocoa-dev]

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:
>> +setAnimationBeginsFromCurrentState:
>> +setAnimationDuration:
>> +commitAnimations
>> etc.
>> 
>> Xcode 11.2.1 says: "'beginAnimations:context:' is deprecated: first 
>> deprecated in iOS 13.0 - Use the block-based animation API instead"
>> 
>> What is this 'block-based animation API’?
> 
> +[UIView animateWithDuration:animations:] and the like. 

That works perfectly!
Thanx!
-Carl

___

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

Thoughts on Objective-C++

[Gabriel Zachmann via Cocoa-dev]

> 
> 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 bugs in the API, because people relied on them, 
because they had worked around them ...

All of which meant that a lot of applications relied on those old API's,
probably through a stack of layers, so that Microsoft could never 
get rid of them.

Occasionally, I still see the "black movie" bug in presentations at conferences.
(Meaning: the movie plays fine on the laptop screen, but on the projector,
there is only a black rectangle.)

So, overall, sometimes, I think, it is just necessary.

A similar case is OpenGl: while it is a real PITA, i think at some point,
the Khronos group had to pull the plug and design a completely new API.

Best regards, Gabriel



___

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 Objective-C++

[Gary L. Wade via Cocoa-dev]

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++, 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
> those are good at turning run-time errors into compile-time.  No multiple
> inheritance, so we had to duplicate code in several places.  No
> initializing members in headers, so mystery bugs if you initialize in the
> wrong type of init.  No public/private to manage access. Etc. It was like
> going back to the early 90s. Doing without features we learned to use the
> hard way.
> 
> Make Objective-C a complete superset of C++ rather than C and it gains all
> the fantastic work that has gone into C++ over the past 20 years. Take
> advantage of folks from many places working on the language, not just half
> or 1/4 of the engineers at Apple.
> 
> Casey McDermott
> TurtleSoft.com
> 

___

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 Objective-C++

[Turtle Creek Software via Cocoa-dev]

>> 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
those are good at turning run-time errors into compile-time.  No multiple
inheritance, so we had to duplicate code in several places.  No
initializing members in headers, so mystery bugs if you initialize in the
wrong type of init.  No public/private to manage access. Etc. It was like
going back to the early 90s. Doing without features we learned to use the
hard way.

Make Objective-C a complete superset of C++ rather than C and it gains all
the fantastic work that has gone into C++ over the past 20 years. Take
advantage of folks from many places working on the language, not just half
or 1/4 of the engineers at Apple.

Casey McDermott
TurtleSoft.com
___

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: Preventing app from being restored or saving info in "Saved Application State"

[David M. Cotter via Cocoa-dev]

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 its own, because it must be launched in 
> a controlled manner and environment from the first app.
> 
> 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.
> 
> 
> I’ve learned that you can do
>   defaults write com.mycompany.myapp2 NSQuitAlwaysKeepsWindows -bool false
> but I cannot ask users to open Terminal.
> 
> Maybe I could use
>   [NSUserDefaults.standardUserDefaults setBool:NO forKey:@“ 
> NSQuitAlwaysKeepsWindows”];
> but i hope there is another way
> /Lars

___

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 Objective-C++

[Jens Alfke via Cocoa-dev]

> 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 open-source 
Foundation was a big roadblock to cross-platform usage of Obj-C. (I tried to 
use GNUstep for a while, but at the time their class libraries were too limited 
and buggy.)

—Jens
___

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 Objective-C++

[Pier Bover via Cocoa-dev]

> 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 only for servers but it's also coming to desktop apps:
https://devblogs.microsoft.com/dotnet/net-core-3-and-support-for-windows-desktop-applications/

On Mon, Nov 11, 2019 at 11:12 AM Jens Alfke via Cocoa-dev <
cocoa-dev@lists.apple.com> wrote:

>
> > On Nov 11, 2019, at 6:15 AM, Turtle Creek Software via Cocoa-dev <
> cocoa-dev@lists.apple.com> 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 you’re wishing for.
> There’s even pretty good interoperability between C++ and Obj-C objects:
> for example you can embed the former as an ivar, or make vectors of Obj-C
> classes.
>
> >  Objective-C and Cocoa will be deprecated soon, replaced by
> > Swift and SwiftUI. That way there is just one shiny new closed system for
> > all Apple hardware. So much simpler.
>
> You can’t really call it “closed” when the entire Swift toolchain and
> runtime libraries are open source, portable, and being actively used on
> other platforms. That’s more open than Obj-C, because Apple never
> open-sourced Foundation.
>
> And it’s much more open than the platform you’re decamping to. MSVC and
> .NET are both fully closed, as far as I’m aware. And I doubt C++-to-C#
> integration is that much smoother.
>
> —Jens
> ___
>
> 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/pierbover11%40gmail.com
>
> This email sent to pierbove...@gmail.com
>
___

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 Objective-C++

[Jens Alfke via Cocoa-dev]

> 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 you’re wishing for. There’s 
even pretty good interoperability between C++ and Obj-C objects: for example 
you can embed the former as an ivar, or make vectors of Obj-C classes.

>  Objective-C and Cocoa will be deprecated soon, replaced by
> Swift and SwiftUI. That way there is just one shiny new closed system for
> all Apple hardware. So much simpler.

You can’t really call it “closed” when the entire Swift toolchain and runtime 
libraries are open source, portable, and being actively used on other 
platforms. That’s more open than Obj-C, because Apple never open-sourced 
Foundation.

And it’s much more open than the platform you’re decamping to. MSVC and .NET 
are both fully closed, as far as I’m aware. And I doubt C++-to-C# integration 
is that much smoother.

—Jens
___

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: UIView block-based methods

[David Duncan via Cocoa-dev]

> 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:
> +commitAnimations
> etc.
> 
> Xcode 11.2.1 says: "'beginAnimations:context:' is deprecated: first 
> deprecated in iOS 13.0 - Use the block-based animation API instead"
> 
> What is this 'block-based animation API’?

+[UIView animateWithDuration:animations:] and the like. 

> -Carl
> 
> ___
> 
> 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/david.duncan%40apple.com
> 
> This email sent to david.dun...@apple.com

___

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

Thoughts on Objective-C++

[Turtle Creek Software via Cocoa-dev]

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
superset of C++ rather than plain C.  Objective-C++ all the way down, not
just in source files.  That would make cross-platform integration much
easier, and solve many of the problems we had.

However, after consideration, it seems obvious that Apple will never do
that. Instead, Objective-C and Cocoa will be deprecated soon, replaced by
Swift and SwiftUI. That way there is just one shiny new closed system for
all Apple hardware. So much simpler.

Maybe I'm wrong, but we have experienced enough past pivots and
bridge-burnings that another seems overdue.

Casey McDermott
TurtleSoft.com
___

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