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: Java 8 use...
Date Tue, 30 Jun 2015 16:30:50 GMT
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 <
> stanislav.muhametsin@kapsi.fi> 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.
>>
>
>


Mime
View raw message