Re: Should we split the project into two branches?

[Andreas Fink]

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 GNUstep
>> libraries don’t use it – it definitely doesn’t keep me from
>> contributing. Most of the code works and is well tested over the
>> years/decades, and so I’m not sure what exactly would be gained by a
>> conversion in comparison to the downside of loosing GCC users.
>
> thank you. As a more recent contributor, your words confort me. True
> that sometimes we had to smooth out some of your commits, but I found
> them and you or other fixed them, to the gain of all.
>
> I continue to think that a restriction into core libraries is
> acceptable, if it leaves the freedom for your "app code" (or... other
> code you need of course).
>
> As if so many people voicing here their opinion are actually
> contributing to core and have difficulties to do that. Most people are
> "users" in the senses I explained in my other mail.
>
> As you write, the loss could be big, but something could be gained: more
> compact code, with possibly (debatable!) less errors.
>
> Riccardo
>
> PS: indeed I think there is no servce in continuing to denigrate our own
> project, including menacing splits or fork. It was my first thought too,
> but I hope it can be avoided, by a single solution with options or
> configurations.


I have written code with and without ARC.
And even if I have tree decades of experience in developing applications
in C and other languages, I still manage to shoot into my foot in memory
management sometimes. It takes a hell of a lot of discipline.
This is one of the reasons why I moved to ObjC in the first place.
retain/release made things much more predictable and use after free
issue basically dissapeared over night. However sometimes I still ended
up in memory leaks because you jump out of a method with an error and
forgot to release what you retained. These are typical errors you will
see in ObjC without ARC and I think you will agree that ALL ObjC
developers have made such mistakes in the past. ARC solves that issue
and makes the life of the developer much much easier.

Im totally aware you can still write code without ARC. I would not have
an issue doing so while contributing to gnustep-base.
What I'm trying to say is that our own experience is not being mirrored
by young developers who came to ObjC in the last 10 years. They might
never have seen retain/release in their life. If you want to attract
such developers to contribute, you have to admit that staying with Objc
1.0 feature set is going to make it much harder for them. Furthermore,
the code is going to be overloaded with much more complex statements
than in ObjC 2.0.

Things like

    myDict[@"somekey"] =@"somevalue";

 is much quicker to write than

    [myDict setObject:@"somevalue" forKey:@"somekey"];


If you have learned the new way, you don't want to go back to the "old" way.
If you learned ObjC in the last 10 year, it will raise a lot of eyebrows
if you have never seen the "old" way.

its like if you force everyone to write Kernigan / Richie C instead of
ANSI C. Sure you can, but whats the point if ANSI-C is todays "standard".
While ANSI-C aged a bit more than ObjC 2.0 since, i still strongly
believe the syntactic sugar of Objc2.0 are highly beneficial to make
code more readable , more understandable.

So by supporting ObjC 2.0 features in the language and the runtime, we
can bring more ObjC developers to GNUStep contribution
By having a version for OjbC 1.0 and a version for ObjC 2.0, you
basically end up having two versions.

In Debian for example, if you do apt-get install gnustep, you end up
with a ObjC 1.0 only version. You can not write any modern apps with
that. Totally wasted.
If you buld a version with Objc2.0 support with libobjc2, then you can
do all the modern stuff, but then you are not backward compatible.

Or put it in other words. We ALREADY have two "branches". Its just not
git branches but how you compile them. So what user A does with GNUSteo
can not be replicated with what user B does.

And that is the conflict which we should solve.

And given GCC doesnt want to learn Obj2.0 support, I believe its going
to be a hard time to keep it in the future. There's a reason why Apple
dropped gcc.