Sync RDF::Trine::NamespaceMap and URI::NamespaceMap

[kasei]

As soon as URI::NamespaceMap is feature-compatible, RDF::Trine::NamespaceMap should be made an empty subclass of it, with appropriate deprecation warnings in the rest of the code to using the subclass instead of the superclass.

[kjetilk]

It should be possible to do this now, I think I have fixed the issue we talked about in release 0.10.

[kasei]

Thanks. I'll look at updating RDF::Trine.

[kasei]

I still don't feel like I'm 100% swapped in on this, but it seems like it might not be as easy as we thought. It doesn't seem to be a drop-in replacement because RDF::Trine code is expecting RDF::Trine::Node::Resource objects back from the namespace expansion, but are instead getting URI objects. I'm not sure where exactly that's happening yet.

[kjetilk]

Right, there has to be some compatibility layer that blesses into Resource objects. Perhaps that's something toby can do with Types::URI.

[tobyink]

I don't think so - type constraints are for coercing and validating incoming data. Here we're wanting to change the class of outgoing data. Currently URI::Namespace is doing something like this:

return URI->new($self->_uri . "$name");

It could instead do something like:

return $self->_uri_class->new($self->_uri . "$name");

Then Trine could subclass URI::Namespace to make sure that $self->_uri_class returned "RDF::Trine::Node::Resource" instead of "URI". And would also need to subclass URI::NamespaceMap to ensure that it used the URI::Namespace subclass instead of URI::Namespace directly.

This would probably require some rethinking the URI::Namespace/URI::NamespaceMap classes first.

[kjetilk]

I just had a quick look at this, and figured it probably didn't make much sense to do a lot for Trine.