Hi Andy,
I guess I don't want to see interface changes ;) We may be able to implement
some reflection logic to
accommodate both ARQ 288 and ARQ 289.
Thanks,
Zhe
On 11/3/2011 3:09 AM, Andy Seaborne wrote:
On 02/11/11 20:11, Zhe Wu wrote:
Hi Andy,
Thanks for your explanation. I know that factory method.
I am wondering if it is possible (or making any sense) to keep the
existing interface (Binding) as is, and introduce a ImmutableBinding
which Binding can extend from?
If any code is doing .add() to a Binding after it has been initiated created,
then ARQ may start producing invalid results, or crash. Bindings must be equals
by value, not by object identity, and got stored in data structures (e.g.
sorting)/ Modifying a binding after it is a parent will invalid assumptions on
variables being bound or not. And you really, really must not add a variable
that already is bound via the parent chain (although this is tested for, I
think).
The old BindingMap is BindingHashMap.
What is the problem you are encountering?
Andy
Thanks,
Zhe
On 11/1/2011 2:54 PM, Andy Seaborne wrote:
On 01/11/11 21:41, Zhe Wu wrote:
Hi,
I am compiling the latest Oracle Jena Adapter Java APIs against the
following libraries and got
"com.hp.hpl.jena.sparql.engine.binding.BindingMap is abstract; cannot be
instantiated"
jena-arq-2.8.9-incubating-SNAPSHOT-tests.jar
jena-arq-2.8.9-incubating-SNAPSHOT.jar
jena-core-2.6.5-incubating-20111024.095834-16-tests.jar
jena-core-2.6.5-incubating-20111024.095834-16.jar
jena-iri-0.9.0-incubating-20111019.130512-8.jar
Seems like BindingMap is now an interface (it used to be a regular
class). Is this an expected change?
Yes.
BindingMap is now the mutable interface to Bindings.
Use BindingFactory.create() to get a BindingMap - the backing
implementation is currently BindingHashMap.
Changes were made to stop accidental modification to Bindings because,
once created they must not change. Create and set a BindingMap -
return a Binding.
Andy
Thanks,
Zhe
Oracle
