[Upstream-devel] Method Format Conventions, Duplicate Code, and Validation Thoughts

[Ryan Z. <zei...@gm...>]

Hey All,
So, first off, apologies for the absolutely monstrous e-mail that I seem to=
=20
have got going on here, I've just thought up a bunch of things that might b=
e=20
fun and exciting for the long term.
Just thought I'd bring up several more points about things that may, or may=
=20
not be useful for the next version. One thing I've noticed is that througho=
ut=20
the trunk, in some places, we use method signatures like=20
obj.this_is_a_method() and in others, namely, mostly in Kayak we end up wit=
h=20
functions like obj.thisIsAMethod(). This is largely a stylistic point, but=
=20
since we decided to standardize on using tabs for indentation, I feel like =
we=20
should probably standardize this as well, along with maybe putting it up on=
=20
the Wiki somewhere, so if we do manage to attract another developer the kno=
w.=20
My personal feeling is that it should be the obj.thisIsAMethod() and=20
this_is_a_static_method() for methods and free functions respectively. I've=
=20
written code the other way, but that sort of seems to make sense to me. Jus=
t=20
thought I'd throw that out there.
The other thing I wanted to talk about, was our current variety of log=20
modules. First off, every module seems to reimplement basic file/pipe=20
reading. My personal feeling on the matter is, we could easily switch to a=
=20
factory pattern where each plugin returns an object for us to use. We could=
=20
conveniently write a base file reader class and a command reader class. Thi=
s=20
could theoretically make writting a new plugin like 2 lines of code. I don'=
t=20
know if this is feasible either, but it might also allow for us to be 1337=
=20
hax0rz and use some kind of pluggable backend for file reading, possibly=20
using either KIO or gnome-vfs if it is present. This is, however, a seconda=
ry=20
concern, the more interesting things come from a reduction of duplicated=20
code. Theoretically, a log plugin could do whatever it felt like, as long a=
s=20
it is extended from some base class that we ourselves implemented abstractl=
y=20
which provides some kind of "read" method, but we could also provide=20
implementations of a file reader and a command pipe reader that sit on top =
of=20
the previously mentioned abstract base class. This would make all sorts of=
=20
things easy. A similar thing could theoretically also be done with submissi=
on=20
modules as well. Obviously, this is somewhat more difficult, as it forces u=
s=20
to design an abstract base class that can handle all of the various post=20
formats that are adopted by the different pastbins. I do however, think tha=
t=20
it could be feasible for us to design an abstract base class that implement=
ed=20
some kind of "non-submit" as well as a fully implemented class that can=20
handle the most obvious cases of submitting to a pastebin. T his would work=
=20
similarly to log modules. If we do it carefully, and put a great deal of=20
thought into the design, I'm sure we could even implement something that=20
might let us get some kind of status back out of the modules. Similarly, I=
=20
know that gnome-vfs and KIO have http and https utilities. We could try and=
=20
implement things in such a way that they rely on these if available. Just=20
some ideas, and thoughts to ponder. This could similarly allow us to ensure=
=20
that in most of the cases, a submit module or a log module could be written=
=20
basically, without almost any knowledge of programming at all. Just copy an=
d=20
paste type stuff.
The final thing that I wanted to propose was our thoughts for validation. I=
=20
know that currently, we do all sorts of validation things. I remember back=
=20
when we were designing things, a conscious decision was made, in order to=20
ensure that no modules that didn't appear to be of the correct type can't b=
e=20
used. Obviously, if we switch to this new factory method, it will be more=20
difficult to determine what we do ahead of time in the case of a module. I'=
d=20
like to propose that validation in the base class be restricted merely to=20
ensuring that a plugin module has the appropriate information that is=20
required to show to the user in the interface, i.e. The name, group, etc. A=
ny=20
other problems we simple deal with at runtime with generic catch-all=20
exception clauses.
So, I know I've written a sizeable chunk, so, just to go back and review, I=
'd=20
like to propose the following style guide for methods throughout the base
static functions: this_is_a_static_function()
class methods: obj.thisIsAMethod()
Also, reworking of the design of the log plugins and the submit plugins to=
=20
provide base classes that can do most of the work, and can be stored in the=
=20
base.
=46inally, the loosening of validation so that modules that will probably f=
ail=20
will be silently dropped at runtime failures, instead of cluttering with to=
ns=20
of debug output about whether the correct various methods and fields are=20
present. I.E. just the current fields, and a check to ensure that an=20
instantiation hook is present.
So, I know that was a rather massive amount of stuff to throw at you, so,=20
please take your time, ponder, tear down, all sorts of fun stuff. I hope al=
l=20
three people who are reading this are doing well ;-).
Regards,
Ryan