> Any other suggestions?!?
Yes.
The whole reason this problem exists appears to be a design choice by the
people who build the Fulcrum security API. It's only apparent purpose is to
provide convenience functions that eliminate the need for variable coercion.
Given Java's lack of templates, this is about the only way you can build
"type-consistent" collections. Whether this is good or bad design is open to
interpretation, but in either case, the implementation currently in the API
isn't really correct.
The idea seems to be that by having SecuritySet.add(Object) throw and
unimplemented exception, it forces people to use the subclasses add(<type>)
methods. Unfortunately, this breaks the contract of the Set interface (well,
maybe just the spirit of the contract).
More correct would be to add the following methods to the subclasses
(RoleSet used as an example):
/* The RoleSet.add method */
public boolean add(Object obj)
{
if (obj instanceof RoleSet)
{
add((Role)obj);
}
else
{
super.add(obj);
}
}
This maintains type integrity and implements the full set interface. This
could be easily added while leaving the existing add(<type>) methods in
place.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
