Hi Rob,

responses inline.

2013/8/26 Rob Lanphier <robla@wikimedia.org>
On Fri, Aug 23, 2013 at 8:03 AM, Denny Vrandečić
<denny.vrandecic@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