> Am 19.03.2018 um 07:19 schrieb amon <[email protected]>: > > I hate to keep pointing it out, but the off the shelf embedded > system we are using is an ARM processor running a circa 2012 > Ubuntu release. They have not changed it in years. We use a > vanilla gcc tool chain. I will do the test compile tomorrow > at work but I very much doubt @autoreleasepool{} exists. > > I will find a work around, and yes, I am indeed that anal. And > I am in aerospace. But I repeat myself... > > Actually I posted that tidbit because it looks to me like the > API violates the intent of the the NS foundation kit standards > as I understand them. It was my impression that every Class > should be instantiable via: > > [[Foo alloc] initMyDesignatedInitializer: vals] > > NSHost lacks any reasonable -init: methods. Not my call if > that is the way folks want it, but it would not be my way > of doing it.
Actually this is not a standard or at least one with quite a few exceptions. When ever it is reasonable that the class should be managing its instances itself, you may find that the alloc/init pattern isn’t used. Or even if it is used something different happens in the background. This occurs for example for subclass clusters, where the main class hides a bunch of implementations in different subclasses or, as with NSHost, cases where the class caches instances. This does not violate your possibilities as a developer and doing it via factory methods is a lot cleaner than the other possibility that gets used too, overriding the alloc method internally. _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
