OpenSAML user discussion

["Scott Cantor" <>]

> I don't know if you consider a SAMLNameIdentifier format handler an
> application,

No, I don't in general. I consider the code that wants to do the comparing
to be the application. In C++, it's not the object that implements the
operator== function, it's the guy sticking them in a container.

> but I claim it's not possible to workaround this problem
> with a handler alone (unless you allow null and empty format URIs in
> formatMap).

I would see no problem with allowing that, it was an oversight. Allowing
that null and empty are the same, of course, which they are.

> > It has the downside of not enabling
> > certain kinds of algorithms, if those algorithms depend on
Object.equals().
> 
> That's why it is generally a good idea to override equals.

Generally. I don't believe this is one of those cases.

> I guess I'm arguing this is too strict for SAMLObjects.

What algorithm would you have me use for objects that are more complicated
and extensible, and what would you tell the next guy who comes along and
doesn't agree with it? Consider that you don't like my definition (which is
a perfectly valid one). Why is mine wrong? It's not, you just need something
different.

Somebody could make a perfectly good argument that for his purposes, your
view of Format="" == Format="unspec'd" is wrong, even though it's true in a
SAML sense. In the current library, while SAMLNameIdentifier can be
overridden somewhat, other classes can't. That's the downside of not doing
everything with interfaces and delegating methods in various ways.

We'll have to see what 2.0 should do, since the design is totally different,
but I can't impose an equals() method of my own without preventing other
people from doing it. The mame identifier class, along with a couple of
others, is basically an exception where it's possibly to hijack the main
class.

-- Scott