So I'm afraid to say that there are some breaking changes coming up in the next release (0.4.1 Beta) of the core library and this blog post describes what they are and how they'll affect your code.
We have not made these changes lightly, these are based on feedback we've received from our users and addresses both this feedback and our own concerns over a limitation in the API. This change is at the fundamental data model part of the API so will likely affect a lot of code, don't panic though the change can be easily accommodated by a simple Find and Replace as I'll detail later.
The problem with our API is that we had 5 different Node Types, the core 3 RDF types - URI, Blank Node and Literal - plus the N3 extension types - Graph Literal and Variable. All these were implementations of one single interface INode. The only way to distinguish between these node types and get at their actual values was to inspect their NodeType property and then cast them to the appropriate concrete type.
And here is where the problem arose, this did not permit for external developers to create their own node implementations since everybody's code assumed the use of the concrete implementations in the core API. So to address this each node type now has a dedicated interface (which extends INode) for it with relevant properties for each node type on it's interace. All code that takes/returns a concrete node implementation now returns the appropriate interface type instead. This has many advantages in terms of extensibility and allowing writing of more generic code.
But it will break your existing code where you've strongly typed/cast things as our concrete Node implementations. For example the following snippet will cause an error under the new release:
Graph g = new Graph();
UriNode u = g.CreateUriNode(new Uri("http://example.org"));
Under the new release it must be changed to the following:
Graph g = new Graph();
IUriNode u = g.CreateUriNode(new Uri("http://example.org"));
You'll notice that the change from a code perspective boils down to just adding an I in front of the class names for each of the concrete node types. Therefore you should find it relatively quick and easy to just do a Find and Replace on your code to fix this issue.
We recommend you do the following Find and Replaces for each node type, we just use UriNode as the example here but you should do this for each node type you use:
"UriNode " => "IUriNode " - Replaces use of concrete type with interface type
"(UriNode)" => "(IUriNode)" - Replaces cast to concrete type with cast to interface type
"is UriNode" => "is IUriNode" - Replaces concrete type check with interface type check
Note: In the first example make sure to include a space at the end of both the find and replace strings otherwise you will change functions names like CreateUriNode which have not changed with invalid names.
Also we would strongly recommend that you do not use the 3rd form in your code anywhere as far as is possible. Anytime you need to check the type of a Node we suggest using the NodeType property instead, once you know the type you can cast to the appropriate interface for that type.
I apologise again for having to break your code outside of a major release but this addresses a limitation with the API which we felt was important to address sooner rather than later especially given the feedback of existing users with regards to this. 13/05/2011 12:44:05 by Rob Vesse in English
Tags: 0.4.1, API, Breaking Changes, Changes, Release