Thanks Quentin, Currently, the EtoileFoundation test suite crashes with GC enabled. This was working a couple of weeks ago - it seems to be related to the use of NSMapTable with weak-to-strong references (these are currently broken in GNUstep - patches welcome...).
Given the large number of new features and the removal of some classes, would it be better to bump the version to 0.5? David On 20 Jun 2011, at 13:55, Quentin Mathé wrote: > Hi, > > I'm glad to announce we are now ready to release EtoileFoundation in the > coming weeks. So testing is welcome! > > All the code changes and even a bit more I had planned have been done. > > I recently rewrote the Trait support, we now support all trait operators > (exclusion, aliasing) and composite trait (a trait with subtraits). > Trait applications are memorized to support composite traits and multiple > trait applications to the same target class. Each time a trait is applied, it > gets validated against the trait tree already bound to the target class. This > ensures operators, overriding rule and flattening property will remain valid > in the new trait tree. Unlike Squeak trait support, a trait can be applied at > any time, and also the way the trait applications are memorized would make > relatively trivial to unapply traits at runtime. > > Here is a small example that applies two subtraits (BasicTrait and > ComplexTrait) to another trait (CompositeTrait), then the resulting is > applied to the target class ([self class]). > > [[CompositeTrait class] applyTraitFromClass: [BasicTrait class] > excludedMethodNames: S(@"isOrdered") > aliasedMethodNames: D(@"lost:", > @"wanderWhere:")]; // -wanderWhere: from Basic method will be renamed -lost: > in CompositeTrait > > [[CompositeTrait class] applyTraitFromClass: [ComplexTrait class]]; > > [[self class] applyTraitFromClass: [CompositeTrait class]]; > > In addition, it's possible to apply a trait without the overriding rule (that > states target class overrides trait methods), which means methods in the > target class can be replaced by methods from a trait. This is a bit closer to > a mixin application, but but its use should be restricted to clever hacks imo > :-) > > [[self class] applyTraitFromClass: [BasicTrait class] > excludedMethodNames: S(@"isOrdered") > aliasedMethodNames: D(@"lost:", @"wanderWhere:") > allowsOverride: YES]; <-- We allow the > trait to override/replace methods in the target class > > Trait applications are commutative, so the ordering in which you apply traits > doesn't matter… but when this mixin-style composition is used, traits are not > commutative and the ordering matters. That's why I'd rather discourage its > use. > > As a concrete example, collection protocols are now implemented by most > classes in Étoilé frameworks through two new ETCollectionTrait and > ETMutableCollectionTrait. See > http://etoileos.com/dev/api/EtoileFoundation/ETCollectionTrait.html > > Unlike in Squeak, you cannot send messages to super in trait methods. It > probably won't change in ObjC in the short term, because the possible > solutions are heavy: > - a new IMP() function that takes an extra argument that allow to evaluate > the value of super when it's late-bound > - trait method must be recompiled per target class > > The last solution shouldn't be too hard to implement in Pragmatic Smalltalk > (or rather LanguageKit). For declaring traits, it would interesting to extend > our Smalltalk parser to support the Squeak syntax. > For the same reason, mixin support has been removed, it is more or less > meaningless, because mixins involve to create new superclasses between the > target class and its original superclass. > > Two other limitations exist: > - trait applications don't take in account class methods > - no mechanism to declare and check non-trait methods required by trait > methods (so you get a runtime exception instead) > > The ObjC trait support in EtoileFoundation is based on: > - http://scg.unibe.ch/archive/papers/Scha03aTraits.pdf (original and short > one) > - http://scg.unibe.ch/archive/papers/Duca06bTOPLASTraits.pdf (most recent and > quite lengthy) > > For all the new features since the last EtoileFoundation release, take a look > at: http://etoileos.com/dev/api/EtoileFoundation/NEWS.html > > To come back to the release topic, EtoileFoundation has now been largely > cleaned and documented. The API documentation is available here: > http://etoileos.com/dev/api/EtoileFoundation/README.html > However there are some undocumented methods or classes, so you are welcome to > write missing documentation (especially if you wrote the code in question :-). > > For the platforms we should concentrate on, I suggest: > - Linux x86 32 and 64 bits > - FreeBSD x86 32 and 64 bits possible > - Mac OS X 10.5 and 10.6 x86 32 and 64 bits (see the Xcode project included) > > Testing (compilation and test suite) against the latest GNUstep releases + > libobjc2 1.4 (GNUstep runtime) with Clang 2.9 is important. As a second > choice, libobjc2 trunk, Clang trunk and GNUstep trunk can be used. > > The code should compile just fine with GCC 4.6 I think, but with > protocol-related warnings probably… at least old Clang version and GCC 4.4.x > doesn't support -Wno-protocol with the same semantic than a recent Clang). > Now I'm not sure about GCC 4.6 compatibility with libobjc2, and whether > EtoileFoundation requires libobjc2 or can be used with GCC 4.6 runtime. I'd > be interested to know about that. > > Based on the feedback I got, I'll post an updated mail on etoile-discuss > (without the trait support explanation) > > That's it :-) > > Cheers, > Quentin. > _______________________________________________ > Etoile-dev mailing list > [email protected] > https://mail.gna.org/listinfo/etoile-dev -- Sent from my STANTEC-ZEBRA _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
