adrianheine added a comment.
I think we should get rid of the idea that people who want to use our data in a
simple and straight-forward way are going to use our code at all. They won't
even use composer for their hacked Wordpress plugin. If people indeed want to
do stuff the right way,
daniel added a comment.
In https://phabricator.wikimedia.org/T118860#1823155, @Bene wrote:
> I wonder if we could just use the decorator pattern (isn't that basically the
> "interfaces" approach?).
With decorators, you can't mix and match: you only have one perspective (role),
and no way to
Bene added a comment.
Thanks for the detailed explanation Daniel, I think I now understand the idea
much better :-)
What I still wonder about currently is however, if we can implement this
pattern without changing our current implementation completely. Although that
is somehow subjective, it
daniel added a comment.
@Bene: the classes in the core model would get a method to get a different
"role" or "facet". That doesn't add much to the data model. If we use the
"alternative implementation" I outlined, this doesn't even add any overhead in
terms of allocated objects.
The easiest
Bene added a subscriber: Bene.
Bene added a comment.
I wonder if we could just use the decorator pattern (isn't that basically the
"interfaces" approach?).
Another idea I found is the Extension Objects Pattern
(http://st.inf.tu-dresden.de/Lehre/WS06-07/dpf/gamma96.pdf,
daniel added a comment.
In https://phabricator.wikimedia.org/T118860#1818705, @JeroenDeDauw wrote:
> I find this approach very odd, do not understand why it would be a good idea,
> and am generally quite worried about it.
>
> My main concern is pretty much described by the first paragraph of
>
Lydia_Pintscher added a subscriber: Lydia_Pintscher.
Lydia_Pintscher added a comment.
I've been asked to comment on use-cases. I do believe we should have good
support for people who write a plugin for Drupal or Wordpress for example that
makes use of Wikidata's data. I do expect a lot more
Lydia_Pintscher added a comment.
3rd party usage in PHP needs to be easy and intuitive, yes.
TASK DETAIL
https://phabricator.wikimedia.org/T118860
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Lydia_Pintscher
Cc: Lydia_Pintscher, mkroetzsch,
daniel added a comment.
@Lydia_Pintscher I take that to mean that we would like such projects to use
our PHP binding of the data model, and we want to make it simple and intuitive
to use the PHP binding with the JSON such 3rd party clients would receive from
our web API. Did I get that right?
JeroenDeDauw added a comment.
I find this approach very odd, do not understand why it would be a good idea,
and am generally quite worried about it.
My main concern is pretty much described by the first paragraph of @mkroetzsch
his first post. I've read through the replies, though found the
daniel added a comment.
In https://phabricator.wikimedia.org/T118860#1813512, @mkroetzsch wrote:
> When things have a conceptual dependency, it is not bad design to have a code
> dependency there as well.
I agree, but that dependency should be as narrow as possible. The code that
creates an
JanZerebecki added a comment.
> When things have a conceptual dependency, it is not bad design to have a code
> dependency there as well.
As far as I understand that, it argues for tight coupling (i.e.
Sites::getSingleton() where the URL is used). Arguing for loose coupling might
read like
mkroetzsch added a comment.
I don't want to detail every bit here, but it should be clear that one can
easily eliminate the dependency to $db in the formatter code. The Sites object
I mentioned is an example. It is *not* static in our implementation. You can
make it an interface. You can
hoo added a subscriber: hoo.
hoo added a comment.
After reading about the role object pattern for a bit, I agree that this is a
good approach. The idea above makes sense to me, I'm just a little worried
about performance (we need to make sure that we don't create to many objects in
the
daniel added a comment.
In https://phabricator.wikimedia.org/T118860#1813397, @mkroetzsch wrote:
> Structurally, this would work, but it seems like a very general solution with
> a lot of overhead. Not sure that this pattern works well on PHP, where the
> cost of creating additional objects is
daniel added a comment.
In https://phabricator.wikimedia.org/T118860#1813279, @adrianheine wrote:
> That looks to me like a fancier and less understandable way of just having an
> `additionalData` hash on each data model object. Did I miss something?
That's pretty much it, yes.
> The Role
mkroetzsch added a comment.
@daniel As long as it works for you, this is all fine by me, but in my
experience with PHP this could cost a lot of memory, which could be a problem
for the long item pages that already caused problems in the past.
> But it requires the serialization and formatting
mkroetzsch added a subscriber: mkroetzsch.
mkroetzsch added a comment.
Structurally, this would work, but it seems like a very general solution with a
lot of overhead. Not sure that this pattern works well on PHP, where the cost
of creating additional objects is huge. I also wonder whether it
adrianheine added a subscriber: adrianheine.
adrianheine added a comment.
That looks to me like a fancier and less understandable way of just having an
`additionalData` hash on each data model object. Did I miss something?
interface AdditionalDataSupport {
function getAdditionalData();
daniel added a comment.
@mkroetzsch You are raising valid points, and we have been over them a few
times in the last weeks. I'll try to briefly explain why we decided against
some approaches:
- core model class knows about all optional information: it pollutes the main
model, and forces
daniel added a comment.
Another advantage of putting the relevant data into the model in a
pre-processing step before output is that it gives us an opportunity do do bulk
queries for labels etc. We'd just get the bulk and inject the info in one go,
instead of snaking it in through the back
21 matches
Mail list logo
