Hi Niclas,
Thanks for comments!
My replies are interweaved below.
On 1.7.2015 16:40, Niclas Hedhman wrote:
A few comments now;
Meta-Info and Uses --> No, they are not really the same. The former is
about providing information to the "Type" but the latter is to provide to
the "Instance". I wouldn't want to merge those.
Hmm, well they are both serving same purpose, just on different levels
("type" vs "instance").
In Qi4CS, the CompositeAssemblyDeclaration in Assembling layer, the
CompositeModel in Model layer, and CompositeBuilder in Instance level
all implement interface which lets you specify values for [Uses] injection.
When the injection value is provided, the Qi4CS first looks up for
suitable value first in Instance layer, then Model layer, and finally
Assembling layer.
This way you can specify the values for "Type" on Assembling level, but
at run-time, you can override those values (if needed) through e.g.
CompositeBuilder.
For me personally, that has worked like a charm.
You may have noticed that I've taken same stance on this issue as with
the @Mixins -> [DefaultMixins] issue: letting the end-user always
override whatever "default" implementation there is.
If there will be need to pass data strictly on "Type" level (this would
mean Assembling and Model layers I think), that can always be added.
Architecture --> There is a concept that might need to be explored further.
In Zest, the Architecture is implicit from the Layer#uses() and other
calls. Perhaps it should be a more explicit concept.
I will be happy to discuss this topic when you will have time and energy
to explore it. :)
C# properties --> I don't know whether that good enough or not. I guess
meta-info isn't of interest, and I assume that there is a way to make them
read-only. Also, since LiNQ can leverage it, I guess there is a reasonable
amount of sophistication, and don't need to elaborate on it.
IIRC Zest Property<T> type also exposes always both setter and getter,
right?
To make one immutable, one applies @Immutable annotation.
In Qi4CS, that is done in similar way, you apply [Immutable] attribute
on a property to make it immutable (once prototype has been instantiated).
Both getter and setter must be present though, in order to be able to
set the property in a type-safe way during prototype stage.
Complex Extensions --> A huge topic, whether it would be possible to make
Storage/Indexing/UoW/EntityComposite as extension to Core. Sounds close to
impossible, considering the handling needed. But perhaps a spike on the
topic would be worth it...
Ah yes, the work to implement this in Zest would be probably quite huge,
since it wasn't designed like that in the beginning.
It was hard, yes, but both Plain Composites and Service Composites in
Qi4CS are implemented using the mechanisms that the Qi4CS Core provides
for implementing any composite type.
So the mechanisms are already in use there and all stuff specific to
certain composite type is decoupled from rest of the Core.
Obviously, if I would start to implement Entity Composite in Qi4CS as an
Extension, I would most likely run into some problems and would need
some small modifications into the types that the mechanisms consist of.
But I don't think there would be anything really serious about it, just
a lot of work.
Application's Name/Version/Mode --> Is still in Zest.
Great, then Qi4CS isn't outdated in that manner. :)
Correction --> Layers can't hold composites in Zest. Those methods are
"selectors" of the composites that are inside modules of the Layer, a bit
like JQuery.
Ahh, okay, good to know!
Annotations for lifecycle methods --> yeah, I remember I suggested that a
long time ago, but one of the problems is another item that you don't touch
on, which also may be implemented differently; namely; Zest will ONLY take
the methods from the declared Mixins that are needed. So if one declares a
Mixin that implements Lifecycle, without Lifecycle being part of the
Composite's type, then those are effectively ignored. Does Qi4CS "glue on"
all Mixins that are declared??
Qi4CS doesn't "glue on" mixins (I actually remember this discussion
about glueing and cherry-picking mixins in old Qi4j mail list).
So it behaves in same manner as Zest then: it will ignore any methods
that are not part of the composite types declared at assembling stage.
However, it does detect during creation of Composite Model if a mixin
has "special" methods (the ones marked with the
Prototype/Activation/Deactivation attributes), and those will then be
modeled as Special Method Models.
So you can have a mixin not implementing *any* of the composite types,
and just having "special" methods, and as long as you have included this
mixin in composite assembly declaration, these methods will be picked up
by Qi4CS.
That said, Paul's "@Activators" construct changes this a bit, I think, as
those are handled explicitly, but that is only for services.
Hmm, I tried to search for "Activator" but I only got commit mails.
Is it an annotation which specifies types which implement Activatable
interface so that Zest would pick them up?
Stan, thanks for the run through, and it gives enough food for thought.
Glad the mail was of use! :)
P.S. When reading my original mail after sending it, I noticed I forgot
to mention that Configuration Composites are implemented as an Extension
in Qi4CS.
They are not a new composite types by themselves, but they provide ways
to read/save other composites, which are the composites which hold
actual configuration data.
