polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: Qi4CS and Zest
Date Wed, 01 Jul 2015 13:40:47 GMT
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.


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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message