> I took a look at your code and while it probably is technically correct,
I think it adds a level of complexity that we as bot developers don't
actually need.
Creating a domain model, which is the direction my code is going, is indeed not the best approach when one only needs to do simple tasks. Transaction scripts typically suffice there. For creating a truly reusable component for dealing with the DataModel, one cannot simply consider the most simple cases though. While a full blown domain model is perhaps not called for, it is useful to embed domain rules into domain objects, and have them properly separated from use case specific logic.
I'm not quite sure what complexity you are referring to. With the approach I am taking, one can hide a lot of complexity, rather then having to deal with it all over the place. Overall the code written so far has (objective) complexity quite a bit below what I saw in pywikipedia. I suspect that what you perceive as complexity is simply the lack of familiarity with the approach taken. Which is actually a quite valid reason to caution against using a domain model, since understanding from the people that are expected to have to deal with it should be held into account.
> we have no need to have different item and item_id classes, they really are basically the same thing for us.
An item is quite different then an item id. There will be cases where you just need to deal with one of them, and places where you have tasks so simple that creating objects such as these does not make sense. If you go treat these things as the same concept, you'll end up shooting yourself in the foot sooner or later, in a similar fashion as making Claim derive from PropertyPage, which also at some point might have seen like a thing you could get away with.
> I wonder if Jeroen looked at the code in compat or in core. Core is
much cleaner than compat. Jeroen?
I agree that sticking to the canonical data model spec is a good idea. Do however keep in mind that the most up to date and accurate spec of what is actually used exists as the PHP DataModel component. If a structurally completely different implementation is made in Python that follows the on-wiki spec, serious problems can be caused by certain kinds of changes. In particular, if the PHP and Python implementations get designed to be open against different kinds of changes, then pain will occur if a change is made in the PHP component that cannot easily be matched in the Python one.
Cheers
-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 --