I agree, only that for fire you just need the person, not the position (imho).
But by now the associations can be part of the private entity implementation.
Automatic mapping from interface methods to association operations is (I think)
out of scope as this is business rule
stuff. And you don't have hire, reassign, fire operations on the
ManyAssociation<Qualifier<Position,Person>>.
This would rather be a part of these extended Association interfaces which
started the discussion.
interface Employees extends ManyAssociation<Person> {
Position position();
or
Property<Position> position();
and
hire(Person, Position);
fire(Person);
promote(Person, Position);
}
Perhaps I have to think about the relationship of qualified associations and
the collection types I try to promote some
more.
Michael
Richard Wallace schrieb:
> I somewhat agree with Niclas, but the other thing that jumps out at me is
> that, rather than
>
> companyEntity.employees().hire( person, ceo );
> companyEntity.employees().reassign( person, ceo, cto );
> companyEntity.employees().fire( person, cto );
>
> wouldn't it be better to have
>
> companyEntity.hire( person, ceo );
> companyEntity.reassign( person, ceo, cto );
> companyEntity.fire( person, cto );
>
> This way the employees association the could be hidden completely, maybe in
> a private mixin, though if you want to make it searchable I think it still
> needs to be part of the public interface which kinda sucks. This is also in
> accordance with the Law of Demeter and it just looks nicer to my eyes.
>
> Rich
>
> On Tue, Sep 9, 2008 at 1:42 AM, Niclas Hedhman <[EMAIL PROTECTED]> wrote:
>
>> On Tue, Sep 9, 2008 at 7:30 AM, Rickard Öberg <[EMAIL PROTECTED]>
>> wrote:
>>
>>> That concludes the quick test I did of this. Is this something along the
>>> lines of what we want? Any pros/cons to it, and can it be improved
>> further?
>>
>> Reflection; I am sure the devil is in the details, and I am not fit to
>> compile all that in my head right now, but if "Role" is a bean with
>> references to two entities, and that this will be searchable, why on
>> earth isn't it just that the Company references an Entity (the Role)
>> which references the "primary Entity" in turn? (Pretty much how we
>> have always done it).
>>
>> interface Company extends Entity
>> {
>> ManyAssociation<Employee> employees();
>> }
>>
>> interface Employee extends Entity
>> {
>> Association<Person> person();
>> Property<String> position();
>> }
>>
>> interface Person extends Entity
>> {
>> :
>> }
>>
>>
>> Right now, I don't see the advantage that clearly...
>>
>> Cheers
>> Niclas
>>
>> _______________________________________________
>> 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
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
