A quick check with Google, and it seems that IEnumerable is more of a combination of Iterable and Stream, since it exposes both those behaviors. A Stream can't be enumerated... But I guess it is the closest you get.
Looking forward to something "juicy"... ;-) On Tue, Jun 30, 2015 at 6:30 PM, Stanislav Muhametsin < [email protected]> wrote: > 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. >>> >>> >> >> > -- Niclas Hedhman, Software Developer http://zest.apache.org - New Energy for Java
