Hehe, yeah, I remember having "TransientComposite"s for a while, but
eventually it didn't really describe the semantics and meaning of that
composite type well enough.
It did take quite a while of thinking to come up with term
"PlainComposite", which is something that tells the reader that this
composite type has all things that are required from a composite, but
nothing extra.
I remember thinking of "NormalComposite" and "BasicComposite", but
neither of those was IMO properly descriptive.
Ah, I think the .NET analogue for "Stream" in J8 would be IEnumerable<T>.
You can do foreach -loops on them and with LINQ you can do filter() etc
operations on it.
So as long as interface exposes an IEnumerable<T>, this enables the user
of the interface to then filter and re-order etc the given items at
their will.
I think the same goes for J8 Stream?
OfTypes() is a hard-coded method, yeah.
That is because the current Assembling API doesn't expose composite
declarations directly.
Ohh, the differences between Qi4CS and Zest!
That is a juicy topic, and I have a lot of things to say about that
(even just terminology-wise).
I will respond with a proper mail later after I've eaten some dinner.
I'll try to keep it very little on technical note and mostly on
terminological note. :)
On 30.6.2015 19:13, Niclas Hedhman wrote:
Thanks for sharing...
PlainComposite --> I like that name better. Any other suggestions instead
of TransientComposite?
Yes, with presence of Java 8 Stream and Functional APIs, I think the answer
is along the lines of what you have done.
module.values() --> should probably return a Stream of "something", which
one can then do filter and other operations on.
I assume that OfTypes() is a hard coded method, and a filter() operation
would take its place in Java. Perhaps like this;
module.values()
.filter( value -> value.types().anyMatch( Task.class ) )
.withTypes( Identity.class );
But my original point was on how close to this we are already...
Stan, it would be awesome if we could converge terminology as much as
possible, so if there are other things that you chose differently (for some
reason), it would be good to hear about them and discuss now.
Cheers
Niclas
On Tue, Jun 30, 2015 at 5:45 PM, Stanislav Muhametsin <
[email protected]> wrote:
On 30.6.2015 18:16, Niclas Hedhman wrote:
Ah! The full expansion of supertypes doesn't affect HasTypes#types() until
after the assembly declarations are completed. I should have realized that
up front.
domainLayer.values( hasTypes -> matchesAny(
type -> Task.class.isAssignableFrom( type ), hasTypes.types() )
).withMixins( Identity.class );
since Task is expected to be a 'hard' super type.
Semi-OT, in Qi4CS (current name) the same is achieved with:
Snippet assembler
.ForExistingPlainComposite()
.OfTypes( typeof( Task ) )
.WithMixins( typeof( Identity ) );
The "ForExistingPlainComposite" returns the same
"CompositeAssemblyDeclaration" (IIRC this is same name as in Zest)
interface as when declaring new composites with the "NewPlainComposite()"
method.
"PlainComposite" here is a Qi4CS term which roughly is same as
"TransientComposite" in Zest.
And "assembler" is architecture-neutral interface allowing the declaration
of composites.
Lately though, I also been thinking of exposing the composite declarations
more directly, like the "values" in your snippet, Niclas.
It would certainly bring more consistency between Qi4CS and Zest.
