ricardo lafuente
2009-06-19 06:52:12 UTC
hai guys,
yesterday, insomnia led to finally trying my hand at refactoring the
Shoebot file structure, and try to separate some of the functionality
into different files. For instance, our Color support is pretty nice,
and would be good to have it importable without the whole Shoebot coming
along.
here's the file structure i created (omitting __init__.py files, which
just import the relevant classes from the module):
src/
sbot
shoebot-ide
shoebot/
core/
bot.py
nodebox.py
canvas.py
cairo_canvas.py
oldbot.py
data/
point.py
grob.py
bezier.py
typography.py
img.py
transforms.py
colors.py
input_devices.py
variable.py
gui/
gtk_drawingarea.py
gtk_window.py
ide.py
socket_server.py
var_window.py
remember, right now all functionality is inside 5/6 files. I'd love to
know if you have alternative suggestions for naming or structuring. Now
that i look at it, i guess the main inspiration for this was the Django
structure.
btw, the names 'typography', 'img' and 'colors' were used because of
possible clashes with existing functions.
pros of this approach:
* at least to me, the program structure looks now much clearer and one
doesn't get so much lost in code; lib2geom transition would also be
easier this way
* now one can do 'from shoebot.core import NodeBot, CairoCanvas' or
'from shoebot.data import Color'
* separate files for each class means module imports are now more
evident -- you can instantly see which modules relate to which class,
instead of that module jumble on top of the file
* namespace fixing; i found some (a lot, actually) of namespace
pollution thanks to 'from data import *' statements. I've been trying to
use Shoebot directly from the interactive prompt and this becomes
evident when you use autocompletion -- tons of names that get imported
for no particular reason. This refactoring goes a long way to rid
ourselves of that.
cons:
* structure changes = possible breakage; i'm now going through a lot of
stuff that broke in the process, and fixing some shortcomings in the
way. It looks stable-ish, but i'm still going to run over it a couple of
times to be sure that there's nothing amiss.
the repo is over at
http://bitbucket.org/rlafuente/shoebot-filestructure/overview/
anyone has any insights to mention regarding this issue? i'd love to
know, wouldn't feel comfortable pushing all this without feedback :)
yesterday, insomnia led to finally trying my hand at refactoring the
Shoebot file structure, and try to separate some of the functionality
into different files. For instance, our Color support is pretty nice,
and would be good to have it importable without the whole Shoebot coming
along.
here's the file structure i created (omitting __init__.py files, which
just import the relevant classes from the module):
src/
sbot
shoebot-ide
shoebot/
core/
bot.py
nodebox.py
canvas.py
cairo_canvas.py
oldbot.py
data/
point.py
grob.py
bezier.py
typography.py
img.py
transforms.py
colors.py
input_devices.py
variable.py
gui/
gtk_drawingarea.py
gtk_window.py
ide.py
socket_server.py
var_window.py
remember, right now all functionality is inside 5/6 files. I'd love to
know if you have alternative suggestions for naming or structuring. Now
that i look at it, i guess the main inspiration for this was the Django
structure.
btw, the names 'typography', 'img' and 'colors' were used because of
possible clashes with existing functions.
pros of this approach:
* at least to me, the program structure looks now much clearer and one
doesn't get so much lost in code; lib2geom transition would also be
easier this way
* now one can do 'from shoebot.core import NodeBot, CairoCanvas' or
'from shoebot.data import Color'
* separate files for each class means module imports are now more
evident -- you can instantly see which modules relate to which class,
instead of that module jumble on top of the file
* namespace fixing; i found some (a lot, actually) of namespace
pollution thanks to 'from data import *' statements. I've been trying to
use Shoebot directly from the interactive prompt and this becomes
evident when you use autocompletion -- tons of names that get imported
for no particular reason. This refactoring goes a long way to rid
ourselves of that.
cons:
* structure changes = possible breakage; i'm now going through a lot of
stuff that broke in the process, and fixing some shortcomings in the
way. It looks stable-ish, but i'm still going to run over it a couple of
times to be sure that there's nothing amiss.
the repo is over at
http://bitbucket.org/rlafuente/shoebot-filestructure/overview/
anyone has any insights to mention regarding this issue? i'd love to
know, wouldn't feel comfortable pushing all this without feedback :)