[Chicago-talk] Basset Bullet Points

Jim Thomason thomasoniii at gmail.com
Mon Mar 28 12:53:46 PST 2005


I've been yapping with Andy. We've come up with some bullet points.

The short blurb is simply that Basset is a framework designed to let
you build your application the way you want to, in a consistent and
easy to maintain way.

So what does that mean?

* It's not just a tool for building websites - you're welcome to build
web apps (it comes with a templating module (if you want to use it)),
but it's equally happy working inside your shell program or a cron job
or in a Tk widget. You can build what you want with it.

* It makes reading from and writing to a persistent object store
(usually a RDBMS) easy - if that's something you want to do. But you
can also build strictly in-memory objects, or widgets, or controllers.
You're not locked in to only building your database model objects in
Basset - you can build -all- your objects in Basset.

* Which leads to the key point - Basset is completely consistent. When
you're working with a Basset object, you know how it's going to
behave. You know how your errors will be reported, you know how your
accessors and mutators will work, you know how introspection
functions. You don't need to worry about your persistence layer not
playing with your root class not playing with your controller not
playing with your templates. It's all the same.

Basically, when using Basset, you can build your entire application
out of legos, instead of building some of it out of legos, some out of
tinker toys, some with an erector set, some with k'nex, and then
trying to balance all of those disparate parts together into something
reasonable. Everything always plugs together in the way it's supposed
to.

* But you're not locked into anything. Since the framework is
completely internally consistent, you can change the parts of it you
don't like and insert new parts that you do. Want to use your own
persistence layer? Drop it in. Want to use your own template? Drop it
in. Missing some snazzy piece of functionality? Create a new module.
As long as you can make your new pieces play by the rules so the rest
of the framework knows that your part will behave the same way it
does, you can use whatever parts you want.

* And you can even change the rules (at least to some extent in some
directions). Don't want to use error codes? Use exceptions. Don't like
how class attributes are created? Re-define it. Basset's key concern
is that you play by the rules, but it's much less concerned with who
wrote the rule book.

* Finally, it's fast (at least relatively speaking). OO in perl is
naturally going to be slightly slower. Persistence layers will
naturally be slower than straight DBI calls. Dispatching takes time.
But it's all been carefully tuned and optimized (and being refined all
the time) to deliver the consistency and flexibility as fast as
possible. So you get improved programmer efficiency and write your
application faster, while not needing to worry about whether your
application is becoming slower in the process.


Thoughts?

-Jim.....


More information about the Chicago-talk mailing list