> Am 25.11.2019 um 11:41 schrieb Maxthon Chan <xcvi...@me.com>: > > Where should we put the creativity to though?
The highest level of creativity is to do both > I would argue that some better places for our creativity to go towards would > be things like our own updating Base, CoreBase and GUI to cover all modern > Cocoa API, Swift standard library, GNUstep Back compatible CocoaTouch and > SwiftUI implementation, Vulcan-based Metal, SpriteKit and SceneKit > reimplementation etc. > > Oh since I mentioned it, if we want to try implementing Metal, we have to fix > Objective-C++ first, which requires clang. GCC’s version of Objective-C is > too broken to support modern features. > > If I recalled it right, some modern Objective-C and Swift features even > requires the use of LLVM libc++ and libc++abi instead of GCC libstdc++. > >> On Nov 25, 2019, at 6:27 PM, H. Nikolaus Schaller <h...@goldelico.com >> <mailto:h...@goldelico.com>> wrote: >> >>> >>> Am 25.11.2019 um 11:21 schrieb Andreas Fink <af...@list.fink.org >>> <mailto:af...@list.fink.org>>: >>> >>> >>>> On 25 Nov 2019, at 11:18, H. Nikolaus Schaller <h...@goldelico.com >>>> <mailto:h...@goldelico.com>> wrote: >>>> >>>> I know that I likely start a flame war, but watching the discussion from >>>> an elevated point of view... >>>> >>>>> Am 25.11.2019 um 10:30 schrieb Gregory Casamento >>>>> <greg.casame...@gmail.com <mailto:greg.casame...@gmail.com>>: >>>>> * Compatibility, much of the API is moving towards using blocks. Blocks >>>>> *ARE NOT SUPPORTED* on GCC and aren't likely to be anytime in the near >>>>> future. >>>> >>>> Hm, where has our own creativity gone? >>>> >>>> Fred mentioned that it could be possible to define some block wrapper >>>> macros if some time is invested. >>>> It that works out, we do not make our decisions depend on gcc *not* >>>> implementing something. >>>> >>>> So this argument for moving to clang looks more like an excuse that we do >>>> not work on our own gcc compatible solution, isn't it? >>>> >>>> -- hns >>> >>> using the same argument you can say we could use assember by creating some >>> tools to output assembler first. >> >> No. We are not talking about different language hierarchies but the same and >> one language feature. >> >>> As David pointed out, its a hell of a lot of work for no benefit and >>> dragging along old workarounds which lead to problems and performance >>> impacts. >> >> Have you even tried? And evaluated what the workarounds and performance >> impacts are? >> >> Nobody has, but you already argue against it. That seems to confirm my >> argument that we have lost creativity... >
