> -----Original Message-----
> From: Danny Angus [mailto:[EMAIL PROTECTED]
> Sent: 06 July 2004 09:53
> To: James Developers List
> Subject: Re: User attribute support and API changes
>
>
>
>
>
> What is your reasoning behind making attribute support a
> seperate interface to Mail or User?
> Do you see any benefit to be gained from this polymorphism of
> Mail and User, or is this just a "tidy mind" encapsulation of
> a single pattern of attribute support?
This is not just a tidy mind thing. But close :)
Eventually when we implement a full MLM the Group objects will
require attribute support for storing items that it needs,
but doesn't need to search on.
>
> FWIW I'm not 100% sure about this, let me elucidate..
> The name can't be used in the sentence "X is an
> AttributeSupport", perhaps if we try "AttributeManager",
> we'll get to...
> "X is an AttributeManager", which I prefer, but also we can
> then see what happens if we add another interface,
> "AttributeContainer" which declares that "X has an
> AttributeManager", accessable through
> AttributeContainer.getAttributeManager()
I think this feels contrived, because I can't see the value in it, but I
could be wrong.
I was originally thinking on the lines of X "has" AttributeSupport, rather
than "is a"
Your solution would mean that to get an attribute value I'd write:
user.getAttributeManager().get("myattr")
Is that what you intended?
I can be persuaded, this is why I'm asking.
>
> We then have two patterns available for attributes
> implementation, one directly through an object which
> implements AttributeManager and one indirected through
> AttibuteContainer.
>
> WDYT?
>
> d.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
