Hi,
yes I think that having the "common denominator" would help on
avoiding to repeat ourselves in various implementations. Methods in
the AbstractExporter could be even final, no needs to provide same
implementation in the different exporters.
the thing is: even if (for example) edge weights are supported in ALL
the file formats of the world (which is quite plausible), the actual
attribute will likely be called in different ways for each format:
"weight", "w", "value" or whatever. So even a unified implementation in
AbstractExporter should still rely on concrete implementations to
discover the name of the attribute (see e.g. the static fields
DotExporter.WEIGHT and DotExporter.LABEL). But it's still fine for me to
keep at least the abstract common denominator.
Another issue I'm facing: some of the output formats depend on the
actual type of the printed value. For example in the DOT format, Strings
(especially those with whitespaces) should be double-quoted while
numbers (doubles) should not, e.g.:
* 192 [label="hello world" weight=3.4]
So we should also seek a unified way to keep track of attribute types
when serializing them, so that each exporter can choose the appropriate
output format for each of them. I saw the
"enlistVerticesProperty"/"enlistEdgesProperty" methods in the code, are
they supposed to help on this matter?
Ciao,
Claudio
--
Claudio Squarcella
PhD student at Roma Tre University
http://www.dia.uniroma3.it/~squarcel
http://twitter.com/hyperboreans
http://claudio.squarcella.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
