Both GNUstep and Cocotron have already achieved this “OS independence and portability” better than you think, on a wider variety of platforms - Linux as well as Windows and FreeBSD. So if you open up the Objective-C compatibility layer and leave the Foundation to them you may have even better OS independence.
> On Dec 4, 2015, at 06:46, Tony Parker <anthony.par...@apple.com> wrote: > > >> On Dec 3, 2015, at 2:37 PM, Jacob Bandes-Storch <jtban...@gmail.com >> <mailto:jtban...@gmail.com>> wrote: >> >> Thanks, Tony. >> >> On Thu, Dec 3, 2015 at 2:33 PM, Tony Parker <anthony.par...@apple.com >> <mailto:anthony.par...@apple.com>> wrote: >> It’s tricky stuff, and the goal is to get it as standards compliant as >> possible. If we use this implementation for all Swift clients then we can >> get a consistent answer everywhere - and even better, fix bugs everywhere at >> the same time. >> >> Agreed. I look forward to it :) I'm just concerned that users will expect >> behavior to exactly match their equivalent Obj-C code. If these bugs are >> fixed / APIs are refined in corelibs-foundation, that expectation might be >> broken. > > Indeed, a very good point and something we are actively thinking about. > > An important goal of our project is to provide a layer of OS independence and > portability. There may be times when we have a bug in the Obj-C > implementation that we therefore decide to reflect in the Swift > implementation as well, because the inconsistency would otherwise be a > problem. Hopefully this doesn’t happen too often. I’d rather fix the bug in > the Obj-C implementation as well, but there are always going to be tradeoffs > to make. > > We have lots of experience making changes to Foundation underneath apps and > keeping things compatible. I think we’ll certainly be using some of that as > we move forward with the Swift Foundation implementation as well. For > example, we may choose to deprecate a confusing (or wrong) API and replace it > with something better. We’d like the bar for changing API to be very high, > though, so that we can provide as much stability to clients as possible. > > Thanks, > - Tony > > >> >> So if you find some of the interface confusing (or wrong), then file a bug >> for us at bugs.swift.org <http://bugs.swift.org/>. We can take this >> opportunity to try to make it better for everyone. >> >> Will do! > > > _______________________________________________ > swift-corelibs-dev mailing list > swift-corelibs-...@swift.org > https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
