Hi,
> Also, there will be lots of Query Api modules in the future
I'm not aware of this being on the roadmap. How did you figure this is
the case?
To be honest because I wanted to implement the queries because they are
really needed for me and other bot operators.
> need their own Api base class.
Since the MediaWiki API has several serious design issues, we seek to
only have minimal binding to it. This means that we will not have
business logic in our API modules themselves, and that there will be
no need for sharing code via inheritance. (Note that sharing code via
inheritance as done by the MW API is one of the design issues we want
to avoid.) An example of a module implemented as we want to do in the
future can be seen here:
https://github.com/wikimedia/mediawiki-extensions-WikibaseQuery/blob/master/src/Wikibase/Query/Api/EntitiesByPropertyValue.php
So the naming problem in question ought to not actually occur.
But I think it would be evil if even the page to query items without
interwikilinks would inherit from the ApiWikibase class because it
provides functions like addSiteLinksToResult, addAliasesToResult or
worse also attemptSaveEntity which really have nothing to do with
quering data. If you see this functions you have to realize that the
ApiWikibase class is only designed for api modules that edit or get
data from one *single* entity. A module that queries data from *lots of*
entities should not be a subclass of this class but however it would be
a ApiWikibase module. This is the reason why the module should be
renamed in my opinion.
Best regards, Bene*
_______________________________________________
Wikidata-tech mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
