[josm-dev] Problem with referrers
Frederik Ramm
frederik at remote.org
Mon Oct 5 08:43:55 BST 2009
Jiri,
Jiri Klement wrote:
> I'm working on support for referrers and I run into a problem which
> I'm not sure how to fix.
Can you explain (or point me to a previous post that explains) what
referrers are good for?
> Currently JOSM quite often makes copies of
> primitive (using for example cloneFrom or special constructors). It's
> not obvious whether the copy is added to the dataset or is kept in
> case we need to get back to old version of primitive (for example
> Command.cloneMap). That's a bit problem because I don't want to have
> such copy in referrers list, I want only primitives that are really
> used in an dataset.
I'm trying to make sense of this (but might go off in the completely
wrong direction here) - you're trying to keep a "breadcrumb" trail of
what happened to an object, is that right? And you want referrer lists
to model that "family tree"?
But why can the list not simply reside on the other side, i.e. in the
descendant object pointing back in history? I have the feeling that
you're duplicating information by distinguishing objects that are
"really used in a dataset" from those that aren't - should not the
dataset itself be the ultimate arbiter on what is "really used" and what
not?
> To workaround this issues I'm thinking about introducing new classes -
> PrimitivePrototype, NodePrototype, WayPrototype and RelationPrototype.
> These classes will hold informations for one primitive, but it will
> not be possible to add these objects to the dataset. That will allow
> to clearly distinguish what's real primitive and whats just an backup
> copy for for example Command.cloneMap or Main.pasteBuffer.
[...]
> This will also fix another issue - for some features (most notably
> reliable events when primitive is modified) I need for every primitive
> to be part of exactly one dataset.
Could one perhaps forgo the prototype objects you are suggesting and
instead create a "backup copy dataset" (that is not associated with a
visible layer); then postulate that every primitive always has to be a
member of exactly one dataset - either a "proper" dataset or the "backup
copy dataset" (or maybe others like it)?
I am not entirely happy with making primitive constructors protected. Is
it so unthinkable that people, e.g. those writing plugins, would like to
use primitives for purposes that are unexpected for us - purposes where
they are not at all interested in things like "reliable events"? Just
because we need that somewhere in JOSM doesn't mean we have to force it
on everybody, or force them to write their own classes instead of
re-using ours. I have a feeling that it would be nice if our Node class
was primarily that - an OSM node - with perhaps some added JOSM bells
and whistles. Maybe, in a way, you were aiming at making your "node
prototype" represent a basic node, and the Node class would play the
role of linking that basic node into the greater JOSM context? But if
that is right, then I guess we should change the naming - i.e. instead
of saying "datasets consist of primitives which are made from
prototypes" we should say "datasets consist of adapter classes (or
linkage classes, or instance classes, or context classes, or wrapper
classes or something) which refer to a primtive". I.e. instead of
further and further mangling the primitive and adding a prototype to its
side, make the primitive into a real primitive (which you called a
prototype) and but all the fancy stuff in the new PrimitiveContext class.
--
When would your prototype objects be created - only on demand or would
they always be there? Say I load a data layer from a file - does that
then create a set of primitives and an associated set of prototypes
(memory issue?), or would the prototype only be generated when required?
How would you manage object identity - could you quickly sketch, for
the following sequence of actions, at what time what prototypes and
primitives would be generated and what OSM ID would be associated with them?
* start JOSM
* load data layer from API
* create new, empty layer
* copy node from data layer
* insert node into new layer
* upload new layer to API
Bye
Frederik
More information about the josm-dev
mailing list