On Feb 17, 2:02 pm, FND <[email protected]> wrote:
> > 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.
To me they are a reasonable place to put what amount to abstract
classes.
> 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?
Do what works?
> > 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.)
In your model who would call that, code that calls tiddlyweb.store, or
tiddlyweb.store calling a StorageInterface implementor? If the former
see my next paragraph. If the latter then go back and read my comments
about making the responsibilities for the developer of a
StorageInterface as explicit as possible again.
In any case, passing a string argument to cause dispatch is really
really ugly. Why not just have get_all_bags()?
> > 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...
Sure, but your thoughts on the matter so far seem to ignore the
impetus of the style of the interface.
> > 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 think so, basically because of the way in which it a) creates an
idiom and grammar I think is sensible b) defines and describes
responsibilities for the developer well. Code serves lots of purposes.
People have a knee jerk reaction wanting to make code as short as
possible. That's fine if you aren't expecting the code to be extended
and adapted, just read. But if you want to enable more than reading,
there's various ways to make the affordances of the code clear.
> I can see that reasoning, but don't necessarily agree (I like minimal
> surface areas).
Sure, so do I, but in my mind your suggestion goes beyond minimal,
sacrificing comprehensibility (on several conflicting dimensions).
> 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.
I disagree. Consider the following example:
One day I decide that TiddlyWeb should have an optional entity called
a Cart (which can hold Bags). I extend StorageInterface to have
cart_get (etc). I make a new release. Everybody out there in the world
still mostly works without change because their stores will raise
StoreMethodNotImplemented if/when something tries to do something with
a cart, and if for some reason that exception is not handled, the
missing method is dead clear: "You need to implement the method X"
without ambiguity.
Not only that, but the code that needs to be changed is _just_ the
addition of 1 to 3 (and maybe 4) methods. In your model (if I'm
understanding you correctly) while you wouldn't need to add another
public method, you would need to hork around in your own personal
dispatch code, choose some private methods to create and otherwise
just not be sure what's going on.
Now you could argue that get() dispatch handling would be defined in
StorageInterface, and there would be some defined set of private
methods in StorageInterface, but then you are just moving the
"problem" somewhere else and making private the responsibilities of
the developer. The things which are important, part of the real
interface, should be public methods described by the interface.
Anything that is private should be something that really is _private_.
>From another perspective:
Consider the mess that is TiddlyWiki methods: when people want to add
functionality, they just add another random parameter to an existing
method, sometimes obsoleting a parameter to such an extent that new
code just passes a null there. All in the name of backwards
compatibility or something. A better option, I think, is to make a new
method, with a different name, with a different set of parameters and
let people migrate to it at their leisure.
Ambiguity is often bad.
Stability doesn't mean that things don't change, it means that known
things remain known.
So given all that, why do I allow get() in tiddlyweb.store when I
don't want it in tiddlyweb.stores.StorageInterface?
This is because of who the user of the code is and what narrowness
means in each particular use context. As I've said before the
StorageInterface is a cognitive aid for a developer. It's an explicit
list.
Meanwhile in tiddlyweb.store get() the caller knows the kind of thing
they have and then just want to get it. The code they are writing is
not about storing a specific thing in a specific way. It is about
getting something, anything.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
