[LV2] Simplifying the Atom model

David Robillard d at drobilla.net
Sun Feb 10 12:30:48 PST 2013

On Sun, 2013-02-10 at 13:02 +0100, Stefan Kersten wrote:
> On 10/02/2013, at 04:39, David Robillard <d at drobilla.net> wrote:
> > On Sat, 2013-02-09 at 23:43 +0100, Stefan Kersten wrote:
> >> On 09/02/2013, at 22:37, David Robillard <d at drobilla.net> wrote:
> >>> On Sat, 2013-02-09 at 12:40 +0100, Stefan Kersten wrote:
> >>> [...]
> >>>>> In short, I think it would be much more obvious if we simply had one
> >>>>> "Object" type.
> >>>>> 
> >>>>> The solution is to merge the classes, and use a signed int32_t as an ID,
> >>>>> where positive is a URID, and negative is a blank node ID (essentially
> >>>>> meaningless outside local context).
> >>>> 
> >>>> imho the current scheme is not confusing at all but rather makes the distinction between blanks and resources explicit instead of relying on a convention.
> >>> 
> >>> The only difference is the ID, though.  In practice this means you get
> >>> type == uris->atom_Resource || type == uris->atom_Blank everywhere, when
> >>> you actually don't care about the type at all.
> >> 
> >> maybe just adding an is_object helper would do the trick? that's what i'm using in my code now.
> > 
> > As does the examples, as do a ton of plugins that copy them.
> > 
> > Seems clear this is just generally more of a nuisance, what's the
> > advantage?  There is the argument that it shouldn't be changed just
> > because it shouldn't be changed, but in general it seems pretty clear to
> > me now that this way sucks, the type hierarchy is weird and pointless.
> imo the current design, which makes an explicit distinction between distinct datatypes is better than merging the types but having different semantics of the type field depending on its value (not only affecting the atom but also the urid extension). the nuisance you refer to above could be alleviated by adding one helper function to atom.h.

But they *aren't* distinct data types!  That is the point.  They are
exactly the same datatype.

It is a straight up incorrect model.  Blank nodes and named resources
are *not* a different type of thing.  They just have a different kind of


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.lv2plug.in/pipermail/devel-lv2plug.in/attachments/20130210/30a63828/attachment-0002.pgp>

More information about the Devel mailing list