[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Should we split the project into two branches?
From: |
Max Chan |
Subject: |
Re: Should we split the project into two branches? |
Date: |
Tue, 15 Feb 2022 07:19:58 -0500 |
> On Feb 15, 2022, at 7:24 AM, Riccardo Mottola <riccardo.mottola@libero.it>
> wrote:
>
> Hi Max,
>
> Also, swift is designed to be objective-c interoperable. So while I
> don't use it myself, it should not require a rewrite ot core.
I have actually asked on the Swift folks on their reason why they do not enable
interoperability on the open source release even if it is there in the code,
their response is that they tried GNUstep and libobjc2 but it failed their QC
so they have to stub out that feature for now. It is designed to be
interoperable, but it needs a compatible, sufficiently modern Objective-C
runtime and library to be interoperable, and we are failing that.
As of rewriting the core, the purpose is to shed unnecessary dependency and
memory footprint once we gained Swift support. There is no point to force every
single Swift program built with GNUstep to operate in full interoperability
mode with the entire Foundation loaded into memory, thus the rewrite making
CoreFoundation taking up the role as the minimal common code base between
Foundation and Swift Standard Library with toll-free bridging implemented, so a
minimal Swift-only program can operate without too many Objective-C in memory
at all. Keep in mind CoreFoundation was initially the minimal common code base
to support both Foundation and Carbon at the same time.
As of the whole Mac OS X 10.6.8 reference, that is the version of Objective-C
language GCC supports even to this day. I acknowledge Base have more features
than Foundation as of Mac OS X 10.6.8, but our internal implementation is still
based on what 10.6.8 in order for them to be built using GCC, thus those are
all backports instead of proper modern implementations. If we want the core to
progress beyond 10.6.8, we have to either fix GCC or abandon GCC. Keep in mind
that if we want Swift, we are very likely have to rebase the core itself and
break GCC compatibility.
> Riccardo
signature.asc
Description: Message signed with OpenPGP
- Should we split the project into two branches?, Max Chan, 2022/02/14
- Re: Should we split the project into two branches?, Richard Frith-Macdonald, 2022/02/14
- Re: Should we split the project into two branches?, Max Chan, 2022/02/14
- Re: Should we split the project into two branches?, Richard Frith-Macdonald, 2022/02/14
- Re: Should we split the project into two branches?, Andreas Fink, 2022/02/14
- Re: Should we split the project into two branches?, Frederik Seiffert, 2022/02/14
- Re: Should we split the project into two branches?, Frederik Seiffert, 2022/02/14
- Re: Should we split the project into two branches?, Riccardo Mottola, 2022/02/14
- Re: Should we split the project into two branches?, Max Chan, 2022/02/14
- Re: Should we split the project into two branches?, Riccardo Mottola, 2022/02/15
- Re: Should we split the project into two branches?,
Max Chan <=
- Re: Should we split the project into two branches?, Andreas Fink, 2022/02/15
- Re: Should we split the project into two branches?, Max Chan, 2022/02/15
- Re: Should we split the project into two branches?, Andreas Fink, 2022/02/15
- Re: Should we split the project into two branches?, Max Chan, 2022/02/14
- Re: Should we split the project into two branches?, Gregory Casamento, 2022/02/14
- Re: Should we split the project into two branches?, Max Chan, 2022/02/14
- Re: Should we split the project into two branches?, Gregory Casamento, 2022/02/15
- Re: Should we split the project into two branches?, Max Chan, 2022/02/15
- Re: Should we split the project into two branches?, H. Nikolaus Schaller, 2022/02/15
- Re: Should we split the project into two branches?, Max Chan, 2022/02/15