Qi4CS and Zest

[Stanislav Muhametsin <st...@zest.mail.kapsi.fi>]

Hello,

As Niclas mentioned earlier in another thread, it is probably best to 
get terminology straight when talking about the Java and C# versions of 
Zest.
For new people or those who just happened to forgot, I am the person who 
"ported" Zest from Java to C#, so I guess I am the right person to 
explain how things are on C# side.
I assume here that readers are at least somewhat familiar with Zest 
codebase and how things work 'under the hood'.

I am going to talk about "Qi4CS" as "Zest ported to C#" since that is 
the current name of the framework (since Zest used to be Qi4j).
There has been talk about Qi4CS moving to be as sub-project of Zest, but 
that will happen after I've refactored the code generation framework 
Qi4CS uses, and when I have time and energy to face the bureaucracy of 
that moving operation.
So for now, "Qi4CS" is basically Zest on C#, and just "Zest" is Zest on 
Java.

My knowledge of Zest codebase might be outdated for some parts, so feel 
free to correct me when I say something that isn't anymore in Zest codebase.
This is quite lengthy mail, but I think and hope that reading all of 
this will create some thoughts and pondering for Zest as well. :)



To start, Qi4CS has the same architectural principle as Zest, namely 
having a Core and then Extensions to interact with other frameworks.
The Qi4CS Core has same components as Zest Core, namely "API", "SPI", 
"Bootstrap", and "Runtime".
They have roughly the same responsibilities as in Zest as well, where 
API types are meant to average every-day user of Qi4CS/Zest, SPI types 
are meant for people writing Extensions/Libraries/etc for Qi4CS/Zest, 
and Bootstrap types are meant for average user to set up a Qi4CS/Zest 
application.
The first difference comes in Runtime component: Zest Runtime is 
"private implementation" of API and SPI components, where Qi4CS Runtime 
is "default implementation" of API and SPI components, additionally 
exposing some types to create more complex Qi4CS Extensions (more of 
that later).

All the main components of Qi4CS Core (and Extensions) are structured by 
having 3 layers: Assembling, Model, and Instance.
The Assembling layer contains types relevant to bootstrap stage of the 
Qi4CS application.
The Model layer contains types relevant to code generation related to 
and verification of Qi4CS application.
Finally, the Instance layer contains types relevant to running and using 
the Qi4CS application, and instantiating and using composites.

The Qi4CS provides two composite types: Plain Composite and Service 
Composite.
The Plain Composite is roughly equivalent to Transient Composite in 
Zest, and Service Composite is exactly the same as in Zest.
There is no Entity Composites in Qi4CS (Core), because I think the 
concept is too application-specific to be included to Core (in the 
projects I've worked, the current entity concepts in Zest are unfeasable 
due to very unusual requirements and design of the environment as a whole).
Nor are there Value Composites either, since I found them to bring 
little new to the Plain Composites.
To counteract the lack of composite types, the Qi4CS Core provides types 
and mechanisms to include new composite types (for example, Entity 
Composite similar to the one in Zest) via Extensions.
These kind of Extensions are the "more complex Qi4CS Extensions" 
mentioned earlier, and the mechanisms to implement this kind of 
functionality are found in Runtime Core component.
On a better side (IMO), the Core is thus much more light-weight, since a 
lot of stuff is now missing from there: all Entity-related things 
(Entity Composite, Entity Stores, Indexing Stores) and Query API/SPI.

Starting to assemble Qi4CS application always starts with the selection 
of suitable architecture.
In Zest, it is assumed that all applications adhere to layered 
architecture, and indeed almost any other architectures can be modeled 
using layered architecture.
The Qi4CS Core works differently, it provides two architectures 
(Singleton and Layered) in Core, and also provides mechanisms and types 
to create custom architectures, should the need arise.
Because of this, the Qi4CS Core actually has one more architectural 
component, in addition to API, SPI, Bootstrap and Runtime: Architectures.
This component corresponds more to the "private implementation" style 
present in Zest Core Runtime, and contains the implementation of 
Singleton and Layered architectures.

During bootstrap stage, the composites in Qi4CS are added to the 
architecture-neutral unit called Assembler.
Singleton architecture has one assembler, accessible directly from the 
main architecture instance.
Layred architecture has layers, each containing modules, and the modules 
then have the assembler.
Notice that unlike Zest, layers and layered architecture itself can not 
hold composite declarations, as they do not have assemblers.
This was initially done for simplicity's sake, and currently there has 
not been any need to change that.
All composite declarations have familiar (for Zest user) functionality 
related to fragments: Mixins, Concerns, Side-Effects and Constraints.
All bootstrap-related types are located in Assembling -layer of Qi4CS 
Core and Extensions.

Once the architecture has been assembled, a model for the application 
and composites is created based on the composite declarations in 
architecture.
Each composite model has a coherent and simple way of examining what 
kind of methods it has, and how various fragments participate in each 
method.
All of the models are verifiable, and creating application instance is 
only possible for verified and valid models.
Like in Zest, there is code generation involved.
However, since CLR type system and the VM in general is much more 
complex than Java, the code generation is optimized to happen during 
compilation stage.
It is possible to generate code programmatically, but one will need the 
"SDK" edition of Qi4CS for that.
All model-related types are located in Model-layer of Qi4CS Core and 
Extensions.

After model is created, validated and the code has been generated, the 
application instance may be created.
Just like in Zest, the Qi4CS application instance has Name, Version and 
Mode (although I am considering removing these, currently there are not 
useful at all, and IIRC they are not present in Zest anymore either?).
And just like in Zest, the Qi4CS application has to be activated before 
it can be used.
All instance-related types are located in Instance-layer of Qi4CS Core 
and Extensions.

The Activation and composite Lifecycle hooks in Zest are accessible by 
implementing Activatable and Initializable (IIRC) interfaces.
The Qi4CS takes different approach: one can annotate the methods on 
fragment types with attributes (C# attributes are roughly same as Java 
annotations) called Activation, Deactivation, and Prototype.
I think this was something that Niclas suggested on Qi4j list ages ago, 
and since I was writing Qi4CS at that point, I decided that instead of 
using interface-implementation-based approach, I would use this 
attribute-based approach.
Personally, I think this approach worked out a lot more better than 
interface-oriented approach, since I can use method parameters to inject 
stuff needed only at certain lifecycle stage (instead of creating and 
injecting to fields).
The "hook" methods will be called by Qi4CS in appropriate lifecycle 
stage of the composite.
Methods marked with Prototype attribute will be called when the 
composite is instantiated from the composite builder.
Methods marked with Activation/Deactivation attribute are only 
meaningful for Service Composites, and will be called when the Service 
Composite is activated/deactivated, respectively.

I've also changed the semantics of @Mixins, @SideEffects and @Concerns 
annotation a bit.
In Qi4CS, they are called DefaultMixins, DefaultSideEffects and 
DefaultConcerns, because the runtime will look up fragments from these 
attributes only if no suitable fragments are provided via "contextful 
methods" (e.g. WithMixins, WithSideEffects, WithConcerns methods found 
on composite declaration during bootstrap stage).
Rationale for this is that IMO the person who actually assembles the 
application should have maximum control over what kind of implementation 
there actually is, and should have ability to "override" the default 
behaviour.

The ModuleInstance in Zest seems to have a lot of responsibilities 
(being architectural unit, also providing composite factories, service 
finders, entity and uow stuff, etc).
In Qi4CS, these responsibilities are moved to a architecture-independent 
unit (on instance level) called Structure Service Provider.
In singleton architecture, the application instance has one SSP directly 
accessible from it.
In layered architecture, each module instance has one SSP accessible 
from it.
The SSP may also be accessed via injections.

The functionality similar to Configuration Composites in Zest is present 
in Qi4CS, but they are not a composite type by themselves.
Instead, there is a ConfigurationManager service, which will create 
ConfigurationInstance<T> plain composites (yes, generic type 
composite!), where T is actual type of configuration composite.
Usually T is other plain composite as well, its state is populated 
during deserialization stage.
The Configuration Composite concept is completely decoupled from Service 
Composite concept.

I also combined the concepts of MetaInfo and @Uses-injection into one in 
Qi4CS.
I found them to be very similar (both are used to pass data from 
"outside" of the Qi4CS/Zest scope), and compacted them into one.
The Uses-injection accepts optional String to distinguish between 
different meaning of the object of same type ("named" objects).
For example, one could have two fields, both of integer type, one with 
[Uses("MyFirst")] and second with just [Uses] attributes.
When e.g. creating composite (or already at bootstrap/model stage), one 
can provide the value for first integer calling .Use("MyFirst", 5) and 
the value for second integer by calling .Use(6) methods.

For model layer, it is sufficient to say that I pretty much wrote that 
from blank state.
Each composite model has Composite Method Models, Special Method Models, 
Constructor Models, and Field Models.
Composite Method Models then each have Parameter Models, Concern Method 
Models, Side Effect Method Models and one Mixin Method Model.
Parameter Models describe possible injections and constraints this 
Composite Method Model has.
Each of the Concern/Side Effect/Mixin Method Model represents a single 
method from a single fragment, and thus the control flow of this 
Composite Method Model can be deduced from those models.
Special Method Models are any method of the fragments marked with 
"special" attribute (e.g. Activation/Deactivation/Prototype discussed 
above), and also have Parameter Models to describe the parameters.
Constructor Models are for each constructor of fragments that the 
composite is made of, also having Parameter Models to describe parameters.
Field Models describe the injected fields of the fragments.

Since C# has concept of properties defined in its language, there is no 
Property<T> in Qi4CS.
Instead, in order to create a property which is part of composite state, 
one does something like "String MyProperty { get; set; }" for interface, 
and then just leaves the implementation out (by having fragments 
implementing that interface leaving the property as abstract).
The Qi4CS detects this situation and during creation of the model, 
delegates the implementation of the setter and getter -methods to the 
generic mixin.
(The similar logic works for C# events, for those familiar of them.)


Phew, what a long mail.
I've most certainly forgot some stuff, but feel free to ask and discuss 
the things I mentioned so far! :)

Re: Qi4CS and Zest

[Stanislav Muhametsin <st...@zest.mail.kapsi.fi>]

On 2.7.2015 1:29, Kent Sølvsten wrote:
> Next thought: We really want some of the composite types to be explicit
> for application writers - but it would be nice to allow adding new
> composite types (messages). Hmmmm, could a Module be some sort of
> (structural/architectural) Composite, too? Composes of some
> entity-handling/value-handling/service-handling. Obviously that could
> lead to some chicken and egg problem (or "It's turtles all the way
> down"). But would represent an awesome fit with the vision of Qi4J as
> "composite-oriented programming" - hmmmm could we consider services as
> properties on a module ?
>
> Maybe adding new features to a basic ModuleComposite is really what we
> need for a proper handling of spatial extensions too?
>

I like this idea of having Module as Composite.
In Qi4CS, I think this would mean the StructureServiceProvider to be a 
Composite.
I have to investigate further into this! :)

Re: Qi4CS and Zest

[Niclas Hedhman <ni...@hedhman.org>]

On Thu, Jul 2, 2015 at 12:29 PM, Stanislav Muhametsin
> Perhaps Zest already has the Assembling/Model/Instance layers, but not as
> explicit as in Qi4CS. :)

Yes, it is an implementation detail. And in fact, it has been re-written
twice without much breakage in API.

Chers
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: Qi4CS and Zest

[Stanislav Muhametsin <st...@zest.mail.kapsi.fi>]

On 2.7.2015 13:15, Niclas Hedhman wrote:
> Well, I don't think I grasp that idea yet.
> As Zest is now, during bootstrap, the user define the Assembly, which is
> used to create the Model, from which the Instances are created and bound.
> But I somehow have a gut feeling that your "Model" is not the same concept
> as the Zest "Model".

It is very much the same as in Zest then - most likely just very 
different API. :)

> It was decided a long time ago, that allowing types to morph in runtime is
> an anti-pattern and practically creates more problems than it solves. Not
> sure if you are suggesting that you are actually supporting that, i.e.
>     AnimalComposite something = ....;
>     typeManager.addType( something, Prey.class );
>
> In the primordial version of Qi4j, that was possible, but really makes the
> brain tired and troubleshooting a hair-pulling contest.
>

Ah yes, the models in Qi4CS are immutable as well, once they are created.
So you can't do that in Qi4CS - just like in Zest, all mutable 
operations (introducing composite types and fragment types) are done on 
assembling level.
One serious problem mutable models would create in Qi4CS is that code 
generation would get broken (or CLR assemblies would need to be re-emitted).

Perhaps Zest already has the Assembling/Model/Instance layers, but not 
as explicit as in Qi4CS. :)

Re: Qi4CS and Zest

[Niclas Hedhman <ni...@hedhman.org>]

Well, I don't think I grasp that idea yet.
As Zest is now, during bootstrap, the user define the Assembly, which is
used to create the Model, from which the Instances are created and bound.
But I somehow have a gut feeling that your "Model" is not the same concept
as the Zest "Model".

It was decided a long time ago, that allowing types to morph in runtime is
an anti-pattern and practically creates more problems than it solves. Not
sure if you are suggesting that you are actually supporting that, i.e.
   AnimalComposite something = ....;
   typeManager.addType( something, Prey.class );

In the primordial version of Qi4j, that was possible, but really makes the
brain tired and troubleshooting a hair-pulling contest.


On Thu, Jul 2, 2015 at 11:55 AM, Stanislav Muhametsin <
stanislav.muhametsin@zest.mail.kapsi.fi> wrote:

> On 2.7.2015 9:39, Niclas Hedhman wrote:
>
>> All these "advanced usecases" points towards what Kent is hinting; A major
>> design overhaul.
>>
>
> A thought for major design overhaul: I can recommend based on experience
> that it would be a good idea to have Assembling/Model/Instance layers in
> Zest as well.
> Basically for each interface or class that you have, decide which of those
> layers it should go (or in "Common" layer, if it is used in more than one
> layer).
> This will help a lot also with coming up with mechanisms to support
> "Composite Type as Plug-In" -idea.
>
>


-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: Qi4CS and Zest

[Stanislav Muhametsin <st...@zest.mail.kapsi.fi>]

On 2.7.2015 9:39, Niclas Hedhman wrote:
> All these "advanced usecases" points towards what Kent is hinting; A major
> design overhaul.

A thought for major design overhaul: I can recommend based on experience 
that it would be a good idea to have Assembling/Model/Instance layers in 
Zest as well.
Basically for each interface or class that you have, decide which of 
those layers it should go (or in "Common" layer, if it is used in more 
than one layer).
This will help a lot also with coming up with mechanisms to support 
"Composite Type as Plug-In" -idea.

Re: Qi4CS and Zest

[Niclas Hedhman <ni...@hedhman.org>]

Long time ago I suggested something like this;

   Entity = Identity + Meta + Value

where Identity and Meta are Immutable and the Value can only change
atomically.

And then TimeseriesEntity, which stores a timestamped sequence of Values.
(This can't really be modeled effectively at the moment, since one can't
leverage the timeseries support built into Cassandra and possibly other
stores.)


All these "advanced usecases" points towards what Kent is hinting; A major
design overhaul.

Speaking from experience; When the previous major overhauls took place, I
and Rickard basically spent hours on the whiteboard trying to figure out
how it was going to work. It was tiresome and painful, discussion mixed
with coding, and most importantly Rickard's ability to crank out working
code in no-time, something now not available.

Soooo, to avoid taking more water over our heads than can be handled, I
think a couple of smaller experiments will be needed;
  a. Find out whether UnitOfWork can be divorced from.
  b. Find out whether Module can become a Composite and customizable.
  c. Find 10 people willing to do the work. ;-)



Exciting, yes. Scary, yes...


Niclas

On Thu, Jul 2, 2015 at 12:29 AM, Kent Sølvsten <ke...@gmail.com>
wrote:

> Wow!
>
> A lot of interesting food for thought going on recently!
>
> A short while ago Niclas began thinking about messaging - And
> introducing MessageComposites with as yet unspecified behaviour.
> Something seemed wrong - but I was unable to fingerpoint it .... But
> somehow introducing a new composite type seemed wrong.
> Each composite type seems to require us a lot of additions to the core -
> new interfaces/builders/methods on module/assembly - new fields and
> constructor arguments in the instances.
>
> We shortly discussed some UOW stuff - seems like a MessageComposite has
> something entity-like - on the other hand the raw message should be
> immutable, so it is sort of a ValueComposite too.
> It might be durable - which would probably require some persisting of
> it's value coupled with some "metadata" (probably common to all
> messages) - so more Entity similarities.
>
> It could be cool to register a message, using some sort of SPI to handle
> the sending - but using the normal EntityStore to handle persistence
> sonehow - that would fit nicely with letting the message handling be a
> side effect of apply()'ing the UOW.
>
> Could it be possible to handle messages as something built upon entities
> and values - and adding some new stuff - and also magically adding the
> required persistent properties behind-the-scene containing required meta
> data (what is this message, when was it created, to which UOW does it
> belong, has it been sent?) something like that.
>
> That would require us adding a new feature to the core. Currently we
> only add implementations to statically declared methods/properties - but
> could we introduce adding new undeclared properties to a "Message
> composite". It might not be a good idea to allow application code to add
> properties or methods - but allowing the core itself to add properties
> (possibly private as in 'private mixin') - that might not be too bad?
>
> Somehow implement message support as some sort of "plugin" building upon
> existing functionality - under the hood converting creation of a message
> composite to an entity/value pair with some persistence and a
> service/SPI to handle sending the message - maybe a concern to handling
> storage on completion of a UOW.
>
> Another post that caused my head to start spin a bit was Niclas
> discussing entity lifecycle design flaw - and the possibility of using a
> concern there for lifecycle handling - on EntityBuilder#newInstance and
> UOQ#complete() ... this possibility to add stuff on creation/destruction
> is something we already have on services - in the form of
> activate/passivate. Well, both entities and services are composites ...
> could a UOW be a composite too? Speaking of similarities .... A service
> has no state - on the other hand the configuration of a service could in
> some way be regarded as (hidden) properties on the service
>
> And now Stanislav explaining Qi4CS ... no entities ... small core ...
> with "complicated extensions" for handling additional composite types -
> not too far from the message composite thought vaguely described above.
>
> I really like this idea! ... well ... sort of.  One of the ideas of Qi4J
> I found attractive was leaning on the DDD concepts - services, entities,
> values. This should be kept for application writers - but we might be
> able to use the idea internally in the core without exposing the fact -
> maybe, just maybe we could implement value handling as an immutability
> concern on top of a plain composite? Maybe, just maybe we could
> implement entity handling as some services/concerns/mixins on top of a
> PlainComposite (I like that name, too!) - But still keep the types
> explicit in the API/assembly (allowing for ading new types).
>
> Next thought: We really want some of the composite types to be explicit
> for application writers - but it would be nice to allow adding new
> composite types (messages). Hmmmm, could a Module be some sort of
> (structural/architectural) Composite, too? Composes of some
> entity-handling/value-handling/service-handling. Obviously that could
> lead to some chicken and egg problem (or "It's turtles all the way
> down"). But would represent an awesome fit with the vision of Qi4J as
> "composite-oriented programming" - hmmmm could we consider services as
> properties on a module ?
>
> Maybe adding new features to a basic ModuleComposite is really what we
> need for a proper handling of spatial extensions too?
>
> A lot of hairy stuff to digest - no clear thoughts as yet - but still
> interesting... I think.
>
> /Kent
>
>
> Den 01-07-2015 kl. 20:50 skrev Stanislav Muhametsin:
> > 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.
>
>


-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: Qi4CS and Zest

[Kent Sølvsten <ke...@gmail.com>]

Wow!

A lot of interesting food for thought going on recently!

A short while ago Niclas began thinking about messaging - And
introducing MessageComposites with as yet unspecified behaviour.
Something seemed wrong - but I was unable to fingerpoint it .... But
somehow introducing a new composite type seemed wrong.
Each composite type seems to require us a lot of additions to the core -
new interfaces/builders/methods on module/assembly - new fields and
constructor arguments in the instances.

We shortly discussed some UOW stuff - seems like a MessageComposite has
something entity-like - on the other hand the raw message should be
immutable, so it is sort of a ValueComposite too.
It might be durable - which would probably require some persisting of
it's value coupled with some "metadata" (probably common to all
messages) - so more Entity similarities.

It could be cool to register a message, using some sort of SPI to handle
the sending - but using the normal EntityStore to handle persistence
sonehow - that would fit nicely with letting the message handling be a
side effect of apply()'ing the UOW.

Could it be possible to handle messages as something built upon entities
and values - and adding some new stuff - and also magically adding the
required persistent properties behind-the-scene containing required meta
data (what is this message, when was it created, to which UOW does it
belong, has it been sent?) something like that.

That would require us adding a new feature to the core. Currently we
only add implementations to statically declared methods/properties - but
could we introduce adding new undeclared properties to a "Message
composite". It might not be a good idea to allow application code to add
properties or methods - but allowing the core itself to add properties
(possibly private as in 'private mixin') - that might not be too bad?

Somehow implement message support as some sort of "plugin" building upon
existing functionality - under the hood converting creation of a message
composite to an entity/value pair with some persistence and a
service/SPI to handle sending the message - maybe a concern to handling
storage on completion of a UOW.

Another post that caused my head to start spin a bit was Niclas
discussing entity lifecycle design flaw - and the possibility of using a
concern there for lifecycle handling - on EntityBuilder#newInstance and
UOQ#complete() ... this possibility to add stuff on creation/destruction
is something we already have on services - in the form of
activate/passivate. Well, both entities and services are composites ...
could a UOW be a composite too? Speaking of similarities .... A service
has no state - on the other hand the configuration of a service could in
some way be regarded as (hidden) properties on the service

And now Stanislav explaining Qi4CS ... no entities ... small core ...
with "complicated extensions" for handling additional composite types -
not too far from the message composite thought vaguely described above.

I really like this idea! ... well ... sort of.  One of the ideas of Qi4J
I found attractive was leaning on the DDD concepts - services, entities,
values. This should be kept for application writers - but we might be
able to use the idea internally in the core without exposing the fact -
maybe, just maybe we could implement value handling as an immutability
concern on top of a plain composite? Maybe, just maybe we could
implement entity handling as some services/concerns/mixins on top of a
PlainComposite (I like that name, too!) - But still keep the types
explicit in the API/assembly (allowing for ading new types).

Next thought: We really want some of the composite types to be explicit
for application writers - but it would be nice to allow adding new
composite types (messages). Hmmmm, could a Module be some sort of
(structural/architectural) Composite, too? Composes of some
entity-handling/value-handling/service-handling. Obviously that could
lead to some chicken and egg problem (or "It's turtles all the way
down"). But would represent an awesome fit with the vision of Qi4J as
"composite-oriented programming" - hmmmm could we consider services as
properties on a module ?

Maybe adding new features to a basic ModuleComposite is really what we
need for a proper handling of spatial extensions too?

A lot of hairy stuff to digest - no clear thoughts as yet - but still
interesting... I think.

/Kent


Den 01-07-2015 kl. 20:50 skrev Stanislav Muhametsin:
> 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.

Re: Qi4CS and Zest

[Stanislav Muhametsin <st...@zest.mail.kapsi.fi>]

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.

Re: Qi4CS and Zest

[Niclas Hedhman <ni...@hedhman.org>]

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.

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.

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.

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...

Application's Name/Version/Mode --> Is still in Zest.

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.

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??
That said, Paul's "@Activators" construct changes this a bit, I think, as
those are handled explicitly, but that is only for services.


Stan, thanks for the run through, and it gives enough food for thought.


Cheers
Niclas

On Tue, Jun 30, 2015 at 10:13 PM, Stanislav Muhametsin <
stanislav.muhametsin@zest.mail.kapsi.fi> wrote:

> Hello,
>
> As Niclas mentioned earlier in another thread, it is probably best to get
> terminology straight when talking about the Java and C# versions of Zest.
> For new people or those who just happened to forgot, I am the person who
> "ported" Zest from Java to C#, so I guess I am the right person to explain
> how things are on C# side.
> I assume here that readers are at least somewhat familiar with Zest
> codebase and how things work 'under the hood'.
>
> I am going to talk about "Qi4CS" as "Zest ported to C#" since that is the
> current name of the framework (since Zest used to be Qi4j).
> There has been talk about Qi4CS moving to be as sub-project of Zest, but
> that will happen after I've refactored the code generation framework Qi4CS
> uses, and when I have time and energy to face the bureaucracy of that
> moving operation.
> So for now, "Qi4CS" is basically Zest on C#, and just "Zest" is Zest on
> Java.
>
> My knowledge of Zest codebase might be outdated for some parts, so feel
> free to correct me when I say something that isn't anymore in Zest codebase.
> This is quite lengthy mail, but I think and hope that reading all of this
> will create some thoughts and pondering for Zest as well. :)
>
>
>
> To start, Qi4CS has the same architectural principle as Zest, namely
> having a Core and then Extensions to interact with other frameworks.
> The Qi4CS Core has same components as Zest Core, namely "API", "SPI",
> "Bootstrap", and "Runtime".
> They have roughly the same responsibilities as in Zest as well, where API
> types are meant to average every-day user of Qi4CS/Zest, SPI types are
> meant for people writing Extensions/Libraries/etc for Qi4CS/Zest, and
> Bootstrap types are meant for average user to set up a Qi4CS/Zest
> application.
> The first difference comes in Runtime component: Zest Runtime is "private
> implementation" of API and SPI components, where Qi4CS Runtime is "default
> implementation" of API and SPI components, additionally exposing some types
> to create more complex Qi4CS Extensions (more of that later).
>
> All the main components of Qi4CS Core (and Extensions) are structured by
> having 3 layers: Assembling, Model, and Instance.
> The Assembling layer contains types relevant to bootstrap stage of the
> Qi4CS application.
> The Model layer contains types relevant to code generation related to and
> verification of Qi4CS application.
> Finally, the Instance layer contains types relevant to running and using
> the Qi4CS application, and instantiating and using composites.
>
> The Qi4CS provides two composite types: Plain Composite and Service
> Composite.
> The Plain Composite is roughly equivalent to Transient Composite in Zest,
> and Service Composite is exactly the same as in Zest.
> There is no Entity Composites in Qi4CS (Core), because I think the concept
> is too application-specific to be included to Core (in the projects I've
> worked, the current entity concepts in Zest are unfeasable due to very
> unusual requirements and design of the environment as a whole).
> Nor are there Value Composites either, since I found them to bring little
> new to the Plain Composites.
> To counteract the lack of composite types, the Qi4CS Core provides types
> and mechanisms to include new composite types (for example, Entity
> Composite similar to the one in Zest) via Extensions.
> These kind of Extensions are the "more complex Qi4CS Extensions" mentioned
> earlier, and the mechanisms to implement this kind of functionality are
> found in Runtime Core component.
> On a better side (IMO), the Core is thus much more light-weight, since a
> lot of stuff is now missing from there: all Entity-related things (Entity
> Composite, Entity Stores, Indexing Stores) and Query API/SPI.
>
> Starting to assemble Qi4CS application always starts with the selection of
> suitable architecture.
> In Zest, it is assumed that all applications adhere to layered
> architecture, and indeed almost any other architectures can be modeled
> using layered architecture.
> The Qi4CS Core works differently, it provides two architectures (Singleton
> and Layered) in Core, and also provides mechanisms and types to create
> custom architectures, should the need arise.
> Because of this, the Qi4CS Core actually has one more architectural
> component, in addition to API, SPI, Bootstrap and Runtime: Architectures.
> This component corresponds more to the "private implementation" style
> present in Zest Core Runtime, and contains the implementation of Singleton
> and Layered architectures.
>
> During bootstrap stage, the composites in Qi4CS are added to the
> architecture-neutral unit called Assembler.
> Singleton architecture has one assembler, accessible directly from the
> main architecture instance.
> Layred architecture has layers, each containing modules, and the modules
> then have the assembler.
> Notice that unlike Zest, layers and layered architecture itself can not
> hold composite declarations, as they do not have assemblers.
> This was initially done for simplicity's sake, and currently there has not
> been any need to change that.
> All composite declarations have familiar (for Zest user) functionality
> related to fragments: Mixins, Concerns, Side-Effects and Constraints.
> All bootstrap-related types are located in Assembling -layer of Qi4CS Core
> and Extensions.
>
> Once the architecture has been assembled, a model for the application and
> composites is created based on the composite declarations in architecture.
> Each composite model has a coherent and simple way of examining what kind
> of methods it has, and how various fragments participate in each method.
> All of the models are verifiable, and creating application instance is
> only possible for verified and valid models.
> Like in Zest, there is code generation involved.
> However, since CLR type system and the VM in general is much more complex
> than Java, the code generation is optimized to happen during compilation
> stage.
> It is possible to generate code programmatically, but one will need the
> "SDK" edition of Qi4CS for that.
> All model-related types are located in Model-layer of Qi4CS Core and
> Extensions.
>
> After model is created, validated and the code has been generated, the
> application instance may be created.
> Just like in Zest, the Qi4CS application instance has Name, Version and
> Mode (although I am considering removing these, currently there are not
> useful at all, and IIRC they are not present in Zest anymore either?).
> And just like in Zest, the Qi4CS application has to be activated before it
> can be used.
> All instance-related types are located in Instance-layer of Qi4CS Core and
> Extensions.
>
> The Activation and composite Lifecycle hooks in Zest are accessible by
> implementing Activatable and Initializable (IIRC) interfaces.
> The Qi4CS takes different approach: one can annotate the methods on
> fragment types with attributes (C# attributes are roughly same as Java
> annotations) called Activation, Deactivation, and Prototype.
> I think this was something that Niclas suggested on Qi4j list ages ago,
> and since I was writing Qi4CS at that point, I decided that instead of
> using interface-implementation-based approach, I would use this
> attribute-based approach.
> Personally, I think this approach worked out a lot more better than
> interface-oriented approach, since I can use method parameters to inject
> stuff needed only at certain lifecycle stage (instead of creating and
> injecting to fields).
> The "hook" methods will be called by Qi4CS in appropriate lifecycle stage
> of the composite.
> Methods marked with Prototype attribute will be called when the composite
> is instantiated from the composite builder.
> Methods marked with Activation/Deactivation attribute are only meaningful
> for Service Composites, and will be called when the Service Composite is
> activated/deactivated, respectively.
>
> I've also changed the semantics of @Mixins, @SideEffects and @Concerns
> annotation a bit.
> In Qi4CS, they are called DefaultMixins, DefaultSideEffects and
> DefaultConcerns, because the runtime will look up fragments from these
> attributes only if no suitable fragments are provided via "contextful
> methods" (e.g. WithMixins, WithSideEffects, WithConcerns methods found on
> composite declaration during bootstrap stage).
> Rationale for this is that IMO the person who actually assembles the
> application should have maximum control over what kind of implementation
> there actually is, and should have ability to "override" the default
> behaviour.
>
> The ModuleInstance in Zest seems to have a lot of responsibilities (being
> architectural unit, also providing composite factories, service finders,
> entity and uow stuff, etc).
> In Qi4CS, these responsibilities are moved to a architecture-independent
> unit (on instance level) called Structure Service Provider.
> In singleton architecture, the application instance has one SSP directly
> accessible from it.
> In layered architecture, each module instance has one SSP accessible from
> it.
> The SSP may also be accessed via injections.
>
> The functionality similar to Configuration Composites in Zest is present
> in Qi4CS, but they are not a composite type by themselves.
> Instead, there is a ConfigurationManager service, which will create
> ConfigurationInstance<T> plain composites (yes, generic type composite!),
> where T is actual type of configuration composite.
> Usually T is other plain composite as well, its state is populated during
> deserialization stage.
> The Configuration Composite concept is completely decoupled from Service
> Composite concept.
>
> I also combined the concepts of MetaInfo and @Uses-injection into one in
> Qi4CS.
> I found them to be very similar (both are used to pass data from "outside"
> of the Qi4CS/Zest scope), and compacted them into one.
> The Uses-injection accepts optional String to distinguish between
> different meaning of the object of same type ("named" objects).
> For example, one could have two fields, both of integer type, one with
> [Uses("MyFirst")] and second with just [Uses] attributes.
> When e.g. creating composite (or already at bootstrap/model stage), one
> can provide the value for first integer calling .Use("MyFirst", 5) and the
> value for second integer by calling .Use(6) methods.
>
> For model layer, it is sufficient to say that I pretty much wrote that
> from blank state.
> Each composite model has Composite Method Models, Special Method Models,
> Constructor Models, and Field Models.
> Composite Method Models then each have Parameter Models, Concern Method
> Models, Side Effect Method Models and one Mixin Method Model.
> Parameter Models describe possible injections and constraints this
> Composite Method Model has.
> Each of the Concern/Side Effect/Mixin Method Model represents a single
> method from a single fragment, and thus the control flow of this Composite
> Method Model can be deduced from those models.
> Special Method Models are any method of the fragments marked with
> "special" attribute (e.g. Activation/Deactivation/Prototype discussed
> above), and also have Parameter Models to describe the parameters.
> Constructor Models are for each constructor of fragments that the
> composite is made of, also having Parameter Models to describe parameters.
> Field Models describe the injected fields of the fragments.
>
> Since C# has concept of properties defined in its language, there is no
> Property<T> in Qi4CS.
> Instead, in order to create a property which is part of composite state,
> one does something like "String MyProperty { get; set; }" for interface,
> and then just leaves the implementation out (by having fragments
> implementing that interface leaving the property as abstract).
> The Qi4CS detects this situation and during creation of the model,
> delegates the implementation of the setter and getter -methods to the
> generic mixin.
> (The similar logic works for C# events, for those familiar of them.)
>
>
> Phew, what a long mail.
> I've most certainly forgot some stuff, but feel free to ask and discuss
> the things I mentioned so far! :)
>



-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java