|
| From: | Gregory Casamento |
| Subject: | Re: Which ObjC2.0 features are missing in the latest GCC? |
| Date: | Fri, 22 Nov 2019 14:55:00 -0500 |
> Am 22.11.2019 um 15:44 schrieb Andreas Fink <afink@list.fink.org>:
>
> The fact is that gcc can not do ARC. This is the main show stopper for gcc.
> On the other hand, switching from gcc to clang is not a problem for "traditional programming style" programmers.
>
> The only problem I can see is platforms which gcc supports but clang does not. So the real question is are there any users who use ObjC stuff with GnuStep under, lets say strange embedded systems.
> Given ObjC does not have a bright future under gcc anyway (as they have still not implemented ObjC 2.0 features after like 10 years it's out now), does mean it will only get worse.
>
> Besides that we have to consider that sticking to gcc will also hinders newcomers to get involved. And this i I think is a important point.
> The developers hehre with 20 years+ experience will have no problem working around non ARC stuff and going backwords because we all know the old way.
> The youngsters out there however don't. If we want to get Gnustep into the modern area, we will need to be attractive to newcomes and this means keeping up with the modern API's etc. And gcc is miserably failing here. Thats the main problem, not if you don't want to use ARC (which is still fine) or not. Others want to use ARC but can't under GCC.
>
> In other words, going for clang doesnt mean ObjC 1.0 code wont run but it means a lot of ObjC2.0 code will start to run.
This is another discussion I would have preferred to stay out of. We had this and other similar discussions so many times before. To me it just seems not worthwhile to participate once more.
There are many benefits that ObjC 2.0 support with clang could bring, still I can understand why some people prefer to stay with a compiler and a language they know. I myself use gcc and even with its limitations it allows me to do useful programming for GNUstep. And many times gcc has pointed to bugs in the code where clang accepted the code. (The opposite is also true, it really has been good for us to have two different compilers to inspect our code.) What I would never do is to argue for others to use gcc. Just use the compiler you prefer.
And this is where this discussion is getting odd. It has been possible to use GNUstep code in ObjC 2.0 projects, thanks to the great work David has been doing. And if we are honest the work to support this inside of GNUstep wasn’t much. Just using a few macros here and there and things work. We could even go further and have a few more macros that allow us to specify the property attributes in GNUstep base and redefine the ASSIGN, RETAIN and RELEASE etc macros as noops and with a bit of code cleanup GNUstep base could be compiled with ARC. All of this should be possible while still keeping support for gcc. Even for simple block usage I am sure that if David and I set down for a weekend we could come up with a macro to define a callable block (probably without capturing variables and without ARC special cases, just the most common case). It is just that the need for this hasn’t come up.
I really don’t see gcc support is itself holding us back. At least not more than the incomplete CoreFoundation, or the fact that base is not build on top of core base, the binary incompatible of Foundation and GNUstep base or the missing usage of C++ in the implementation of GNUstep. These and some other factors seem more important to me. But if we start to change all of these, the resulting project would be quite different from current GNUstep. And most likely we would have lost most of the current GNUstep developers in the transition process. Nobody can tell whether we would gain new active core developers through this change. I really doubt that and therefor would prefer not to drop gcc support. If you disagree, fine. But for GNUstep it would be great if you could pledge to work on the code in the next few years. Otherwise the project will be dying even faster than it is now.
Fred
| [Prev in Thread] | Current Thread | [Next in Thread] |