> See StorageInterface definition [1], that is the canonical definition
> of the interface, including only those methods which matter to the
> interface. That should be your _formal_ starting point for
> understanding the interface.
Oh right - I have a tendency to ignore __init__.py files because they're
usually(?) empty. That's probably my fault though.
> Officially it is all optional. If you look in tiddlyweb/stores/
> __init__.py you'll see that everything raises
> StoreMethodNotImplemented. If your store implementation doesn't
> implement something that's what will happen. This is used, for
> example, in the googledata store to support not doing revisions.
That's interesting - our store does not support revisions, but we
essentially worked around that by redirecting everything to the tip (so
it's always revision #1).
Perhaps we should change that?
>> * list_<item>
>> * <item>_<put|get|delete>
> [...]
> there's an important distinctions. <item>_{put,get,delete} is
> correct, but it is list_<item>s. That plural-ness is relevant.
Right, that was probably more of a typo on my part.
> The list methods do not accept any singular object as input [...]
> To me this would make the calling code dishearteningly confusing
> and create an idiom that is linguistically awkward.
Well, I'm not sure if I completely follow your reasoning there, but
imagine something like this:
get(bag) # retrieve bag from store
get_all("bags") # retrieve list of bags in store
That seems alright to me. (Obviously there might be a better label than
get_all or list for that method - I'll leave that to the non-ESLs.)
> Much of the semi-identical code is intentional. When I write code a
> first time I will leave the pseudo-duplication in place to better
> understand the problem. If the duplication becomes an issue I'll clear
> it out.
I'm aware of that - but I think we're at that point now where
refactoring would be useful...
>> How about refactoring that interface to use something like list(type)
>> and <put|get|delete>(mode, type), with the respective type-specific
>> functionality delegated to private methods (if required)?
>
> What is "mode" in your text above?
A mistake. (I used to have s/<put|get|delete>/accessor/ there - but that
was more confusing and essentially nonsense, and I forgot to adjust the
arguments when renaming.)
> Like with much of the stuff going on in TiddlyWeb, the
> StorageInterface is at is to make side A of the code stay the same in
> the face of changes on side B and to make the responsibilities of side
> B as explicit as possible. This often means that both sides might
> initially be a bit more fluffy than you really like, but over the long
> run tends to be useful. As long as the interface between A and B is
> tight and clean its a win.
So you're basically saying having separate put/get/delete and list
methods for each entity is concise enough, and better than the
alternative of combining them for all entities?
I can see that reasoning, but don't necessarily agree (I like minimal
surface areas).
Also, with regards to extensibility (while retaining a stable API), it
seems favorable to have methods which can be made to handle one more
entity type rather than adding another set of methods.
-- F.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TiddlyWikiDev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/TiddlyWikiDev?hl=en
-~----------~----~----~----~------~----~------~--~---
