Hi Rob,
responses inline.
2013/8/26 Rob Lanphier <robla(a)wikimedia.org
On Fri, Aug 23, 2013 at 8:03 AM, Denny Vrandečić
<denny.vrandecic(a)wikimedia.de> wrote:
for Semantic MediaWiki we had this already listed
for a while here:
<https://meta.wikimedia.org/wiki/Wikidata/Notes/SMW_and_Wikidata
The list is not completely up-to-date, it
reflects the previous package
structure.
It would be helpful if there was a wiki page that reflected the
current state of things. For MediaWiki core, we're trying to get into
the practice of having RFCs for changes of this magnitude, and
something of that level of rigor would be nice here too.
The current state is described here: <http://www.mediawiki.org/wiki/Wikibase
, more specifically here: <
http://www.mediawiki.org/wiki/Wikibase#Packages_and_code_structure
The new structure was described in Emails on Wikidata-tech, most recently
here: <
http://www.mail-archive.com/wikidata-tech@lists.wikimedia.org/msg00200.html
We are indeed not yet using the RFC process, but I would prefer if we could
agree to move to this process in the future, as this particular discussion
is going on already a bit longer than what I would expect for a discussion
regarding the question about how to organize code.
1. DataValues
Note: In general, DataValues is helpful for
simply handling DataValues
without having to work with them a lot. It is an extremely light weight
container for a data value.
It would be nice to have a less recursive explanation. :-) As near
as I can see skimming the code, this is mainly validation code for
data types that not native to PHP (e.g. LatLong, Time), and wrappers
for ones that are native to PHP (e.g string), providing a consistent
interface to all of them (e.g. getType, getSortKey, getArrayValue,
toArray). Is that it in a nutshell?
I agree that the explanation sounds a bit recursive, this is a "feature"
stemming in the fact that the packages is called DataValues and we (or
maybe it is just me) in general lack a really good non-recursive
terminology for these things. Improvements on the terminological issues are
more than welcome.
Regarding your question: yes, it provides a consistent interface to such
kind of data values (not types) and their common super class so that
different code can deal generically with them. Note that some particular
data values (in particular Coordinates and Time) would be moved to
DataValues Implementation.
2. DataValues interfaces
Is this the code that's currently in ValueValidators?
And ValueParsers and ValueFormatters, for the simple DataValues.
3. DataValues implementations
Is this basically an expanded set of DataValues interfaces, base
DataValues, or something else?
It adds more complex data values, like coordinates and time, that are not
used in most cases, especially for the ParamProcessor, who e.g. should not
depend on the highly complex time parser,.
I'll respond more on the other bits later, but I
wanted to make sure I
at least got this response out now.
Rob
I hope that helps,
Denny