On Sat, Oct 25, 2008 at 15:07, Niclas Hedhman <[EMAIL PROTECTED]> wrote:
> On Fri, Oct 24, 2008 at 6:29 PM, Edward Yakop <[EMAIL PROTECTED]> wrote:
> I fail to see the massive productivity gain you are talking about. And
> assuming for a second that the above is not Queryable, I would still
> suggest that we perhaps support @PropertyField to declare a Property,
> without a corresponding Property in a mixin (public or private).
>
> I agree that Property<type> should most likely never be exposed to
> client code and that the context interface (or whatever we want to
> call it) provides a view of the composite that the client code needs.
> It would also prevent the problem of "random queries" that clients may
> do, which may cause problem to remain compatible with over time.
It is not queryable.
And for dddsample use case where Cargo should be created via BookingService.
Hence, we would need to implement CargoEntity as
class CargoMixin
implement CargoMixin
{
private CargoState cargoState;
CargoMixin( @This CargoState cargoState, @Uses Location origin )
{
this.cargoState = cargoState;
cargoState.origin().set( origin );
}
}
If we have use case where there's more than one immutable field with
the same type e.g.
CarrierMovement#to, CarrierMovement#from,
CarrierMovement#departureTime and CarrierMovement#arrivalTime.
How are we supposed to initialize these fields? It seems to me that we
have no choice but implement this entity
similar to CargoEntity in my previous email.
If we don't want to protect *State, that means, anybody can make random query.
If we want to protect *State by making it package protected (which
this is what I do in dddsample)
That means, every composite would need its own implementation of the
same mixin type.
And this potentially a massive productivity lost.
Regards,
Edward Yakop
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
