One of the features of ARC is weak pointers, which clears itself to nil once
the referenced object is deallocated. Mac OS X 10.6.8 has a backported weak
pointer (the one Derek mentioned) and iOS 4.3.5 does not support weak pointers
at all. This self-clearing behavior of weak pointer is what
> Am 15.02.2022 um 15:10 schrieb Derek Fawcus
> :
>
> I don't know about the level of changes needed in GCC, or about the
> possibility of using an objC preprocessor, but it was possible to
> build and deploy ARC using (including __weak references) code to 10.6.8.
>
> As I recall one had to
I don't know about the level of changes needed in GCC, or about the
possibility of using an objC preprocessor, but it was possible to
build and deploy ARC using (including __weak references) code to 10.6.8.
As I recall one had to build against the 10.7 SDK, and then add an
extra package for the
> On Feb 15, 2022, at 7:10 AM, Andreas Fink wrote:
>
> Question:
> is it time to start working on libobjc3 with Swift support and support
> for all platforms we want to support?
> (if libobj3 is an upgrade of libobjc2 or a rewrite being put aside for now).
Or should we just work backwards,
I mostly haven’t chimed in here because others covered my points for me. But I
feel like reiterating what I said on stream the other night.
As a copyleft and GNU fan, it causes me deep emotional pin that we’re
considering targeting something other than GCC as our primary tool chain.
BUT
We
> On Feb 15, 2022, at 7:24 AM, Riccardo Mottola
> 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
Question:
is it time to start working on libobjc3 with Swift support and support
for all platforms we want to support?
(if libobj3 is an upgrade of libobjc2 or a rewrite being put aside for now).
Apple will run away in a decade with Swift only. So if our goal is to
keep OS X compatibility, then
Hi Max,
Max Chan wrote:
> The problem is that our core libraries are dreadfully outdated. It is on par
> with Mac OS X 10.6.8, which is a decade old now. This whole Next branch idea
> is to remove the restriction on the new branch so people interested in or
> need new features can chase the
> On 14 Feb 2022, at 16:38, Xavier Brochard wrote:
>
> Hi everyone
>
> By reading this discussion, I was thinking there is a problem that no one
> talk about. This email from Riccardo is a good starting point:
>
> Le 14.02.2022 00:11, Riccardo Mottola a écrit :
>> But what is a user? I can
Riccardo Mottola wrote on 15.02.22 00:06:
> Hi Frederik,
>
>
> Frederik Seiffert wrote:
>> I’d never write any new *app* code without ARC, and would definitely
>> recommend converting any existing apps if you can control the
>> environment where they are built, but IMO it’s fine that the
> On 15 Feb 2022, at 08:13, Max Chan wrote:
>
>
>
>> On Feb 15, 2022, at 2:54 AM, H. Nikolaus Schaller wrote:
>>
>>> Am 15.02.2022 um 08:36 schrieb Max Chan :
>>>
>>> Come to think of it, if we do chase the latest feature especially Swift
>>> compatibility, we get Swift Package Manager
This kind of layering is the easiest and the most robust way of implementing
all those toll-free bridging. You can see where NSObject lives as that is
required or toll free bridging to work. Also through my probing a lot of
Foundation classes actually lives in CoreFoundation binary.
If we
> On Feb 15, 2022, at 2:54 AM, H. Nikolaus Schaller wrote:
>
>> Am 15.02.2022 um 08:36 schrieb Max Chan :
>>
>> Come to think of it, if we do chase the latest feature especially Swift
>> compatibility, we get Swift Package Manager along with it which can be used
>> as a parallel build
> Am 15.02.2022 um 08:44 schrieb Max Chan :
>
> This is just whack…
>
> What I mean by saying we need refactoring, is that our library structure is
> twisted and may not bode well for future Swift integration. Here is ours:
>
> * libc
> * libobjc2
>* Foundation (NSObject here)
> *
14 matches
Mail list logo
