On 15 Mar 2011, at 20:16, Reto Bachmann-Gmuer wrote:
>
>
> On Tue, Mar 15, 2011 at 8:13 PM, Henry Story <[email protected]> wrote:
> Those are questions I was asking when looking at the code. Can you answer
> them?
> I just added a new constructor, because the given one was a bit lame. But I
> did not want to replace the one without understanding more. Hence the
> comments below.
> I reposted on mailing list as originally intended.
>
> My asking back to your questions is inline.
>
> Reto
>
>
> Henry
>
> On 15 Mar 2011, at 20:02, Reto Bachmann-Gmuer wrote:
>
>> Hi Henry
>>
>> Could you please fix yesterday's commit? There are still experiments and
>> discussion in it.
>>
>> One discussion (taken from
>> rdf.scala.utils/src/main/scala/org/apache/clerezza/rdf/scala/utils/RichGraphNode.scala):
>>
>> /* because it is tedious to wrap nodes as happens in a lot of code.
>>
>> That's why there are dynamic conversions, the Preamble Object converts any
>> GraphNode to RichGraphNode, instances of the preamble class also convert
>> Resources (such as UriRefs) to RichGraphNodes.
Perhaps, but then sometimes the new constructor is easier than an import
statement.
I found it a bit odd in some code to create an import statement for this.
I think one should not use dynamic conversions unnecessarily. They should be
used carefully when needed.
>> * todo: does one really need to create the graph node? Is there a
>> reason this is passed ike that,
>> What do you suggest, RichGraphNode not to be a subclass of GraphNode?
No, it was just a question there I had not time to answer.
>>
>> * todo: or was that just a quick hack? If it is because we don't
>> want to use any of the superclass implementations
>> Not sure what you're refreing too, RichGraphNode doesn't reimplement any of
>> the superclass methods
I was just wondering why for example
def /(property: UriRef) = {
new CollectedIter(() => new GraphNodeIter(node.getObjects(property)),
readLock)
}
calls node.getObjects() and not just getObjects() since it is extending the
class.
There could be reasons for calling it on node, if one felt that it could
contain behavior that was important. But then the other methods from the
superclass would not be calling it. So that seems wrong.
>> * todo: then it would be worth creating an interface above
>> GraphNode and implementing the interface instead...
>> I see no need for this.
Probably not no. I was just trying to understand what was going on here.
As there is no documentation I put my thoughts in a todo.
Next step is to document the class....
>>
>>
>> Cheers,
>> reto
>>
>>
>
> Social Web Architect
> http://bblfish.net/
>
>
Social Web Architect
http://bblfish.net/
