[LV2] Simplifying the Atom model
sk at k-hornz.de
Sun Feb 10 04:02:11 PST 2013
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.
More information about the Devel