polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stanislav Muhametsin <stanislav.muhamet...@zest.mail.kapsi.fi>
Subject Re: Qi4CS and Zest
Date Wed, 01 Jul 2015 18:50:52 GMT
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.

Mime
View raw message