Rickard Öberg wrote:
> Hey
>
> Interesting questions, and I think private mixins is what you're looking
> for to solve your problems. Comments inline below.
>
> Richard Wallace wrote:
>
>> In the first case, the iterations property should be Immutable because
>> only the ItemStyle itself should manage the collection. But that only
>> limits calling the style.iterations().set() method, but users are free
>> to modify the collection by calling style.iterations().get() and using
>> the regular collection modifiers. Could it, and should it, also make
>> sure that the collection returned by get() is unmodifiable?
>>
>
> What you could do is combine the two alternatives to get the best of
> both worlds. First you do an interface with the SetAssociation, which
> points to Entities. That interface is then *not* included in the
> Composite interface, but is only accessed internally through @This. Like so:
>
> public interface Iteration extends Nameable, EntityComposite {...}
>
> public interface ItemStyle extends Nameable
> {
> SetAssociation<Iteration> iterations();
> }
>
> then the public interface to be included in the Composite:
> public interface ItemStyleAggregate
> {
> ImmutableProperty<Collection<Iteration>> iterations();
> Iteration newIteration(@NonEmptyString String name);
> }
>
> then the implementation of ItemStyleAggregate:
> public class ItemStyleAggregateMixin
> implements ItemStyleAggregate
> {
> @This ItemStyle itemStyle;
> @Structure UnitOfWorkFactory uowf;
>
> public ImmutableProperty<Collection<Iteration>> iterations()
> {
> return new ComputedPropertyInstance<Collection<Iteration>>(...)
> {
> public Collection<Iteration> get()
> {
> return Collections.unmodifiableSet(itemStyle.iterations());
> }
> }
> }
>
> public Iteration newIteration(String name)
> {
> // Check that no iteration with given name already exists
> ...
> UnitOfWork uow = uowf.currentUnitOfWork();
> Iteration iteration = uow.newEntity(Iteration.class);
> iteration.name().set(name);
> itemStyle.iterations.add(iteration);
> return iteration;
> }
> }
>
> This way you can expose an unmodifiable set, and even limit it to be an
> Iterable if you want, and still work with it internally as a fullblown
> Set, with your domain rules being enforced. There's no need to
> "initialize" the property since it is computed on every get.
>
> AFAICT this solves all your requirements. Let me know if something is
> unclear.
>
>
Ok, that's pretty cool. I got it working, but I have to admit I don't
entirely understand _how_ it works. I think I may just be missing the
details behind private mixins. I knew that with mixins you could define
the implementation of the operations for entities and composites, but I
had no idea you could use them to introduce what, I'm guessing, amounts
to private properties. Is it the @This annotation that makes it work?
Does that make that field a field of the composite or entity the mixin
is being applied to?
Pretty cool in any case!
Thanks,
Rich
> /Rickard
>
> ps. This is mail-ware, so there might be some typos in the above.
>
> _______________________________________________
> qi4j-dev mailing list
> [email protected]
> http://lists.ops4j.org/mailman/listinfo/qi4j-dev
>
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
