Opps I accidentally press send email. Please re-read. Sorry.
>> 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.
We might need to create an intermediate CargoService or BookingService
might need to be implemented in
the same package with the CargoModel (more to that later).
There is problem with your implementation. Because origin is an
immutable association.
Hence, we would need to implement CargoMixin as:
class CargoMixin
implement CargoMixin
{
private CargoState cargoState;
CargoMixin( @This CargoState cargoState, @Uses Location origin )
{
this.cargoState = cargoState;
cargoState.origin().set( origin );
}
}
If we look at CarrierMovement, where all its fields are immutable.
Date type:
CarrierMovement#to, CarrierMovement#from
Location association:
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.
This leads to your argument.
If we don't 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).
I need to create CargoFactory and BookingService depends on this.
For every composite that uses mixin type that falls into this use case.
Each composite would need to implement this very same mixin type.
This is potentially a massive productivity lost.
Regards,
Edward Yakop
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
