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
