Re: Blank Nodes Re: Toward easier RDF: a proposal

> On 2 Dec 2018, at 23:54, Thomas Passin <tpassin@tompassin.net> wrote:
> 
> On 12/2/2018 4:31 PM, Henry Story wrote:
>> One could make a similar argument in Java, JavaScript or Scala. In
>> such languages the identity of objects can only be determined by
>> fields of the objects, that is arrows going *from* the object to a
>> literal or another object, as there is no way to determine what objects are pointing to an object O from within O: there is no global
>> object index.  So someone coming from that background would find it
>> odd that arrows pointing to a blank node could make a difference as
>> to the equality of that object.
> 
> I don't think that this is quite right.  The usual objects in OO
> languages know their parent *type* or (prototype).  They don't know
> about any linkages to other objects unless properties are assigned that
> hold that information.  And it's common to provide for such linkages.
> Just think of doubly linked lists, or the XML DOM. 

yes, an object knows its fields, either directly (the link to it's prototype) or indirectly by going through 
a prototype as in JS.

In the case of datastructures like doubly linked lists (or DOM elements) the elements of the chain 
know their successor and predecessor from within. Each link has an extra attribute (named "prev"
in Scala's implementation) that links back. So in order to create a back link you need an extra
attribute in the object.

See Scala code for 
https://www.scala-lang.org/api/2.12.4/scala/collection/mutable/DoubleLinkedListLike.html

>  True, there is usually no built-in object index, but a programmer can provide for one if it's wanted.

Providing an object index can not change the equality (or hash value) of the objects - unless the objects
contain a link to the index, which seems a dangerous thing to do.

> Anyway, garbage collectors need to find all the objects so they can do their job, so in garbage-collected languages the information must be available in some manner.

yes, it is available to the VM, but not to the coder (except as a way to send perhaps a hint to). So from
the code perspective the GC is invisible.
 
The idea is not to say that one way of doing things is right and the other wrong, but to delineate the differences
and then show the mappings from one to the other, so that the pieces fall together nicely.

The task may seem impossible given the huge number of different programming languages,
but luckily there are mathematics of OO programming. I wrote up some pointers I had found
in this Quota answer on the difference between OO and FP
https://www.quora.com/Why-is-functional-programming-seen-as-the-opposite-of-OOP-rather-than-an-addition-to-it/answer/Henry-Story
One would need to complete this with something that fits in with Logic and so Web Logic to complete the
picture.

> 
>

Received on Monday, 3 December 2018 08:18:00 UTC