polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kent SĂžlvsten <kent.soelvs...@gmail.com>
Subject Re: Qi4CS and Zest
Date Wed, 01 Jul 2015 22:29:22 GMT

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.


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.

View raw message