[holy ruby programmers batman!] git/svn/patches?

Giles Bowkett gilesb at gmail.com
Sat Dec 15 22:14:08 EST 2007


Nice one on these specs, Tim. Pretty hard core!

Re-architecting the project is actually totally fine with me in
theory, although in practice the reason everything's tacked onto
Object is because that's how .irbrc does it, and it's what makes
things available at the top-level, so it gives the illusion of being a
Unix shell command. In theory it'd be possible to take the
ActiveRecord approach, i.e., package everything into modules, and then
merge those modules with something like

Object.extend Pastie

That might actually be a cleaner way to do a feature I have to add.
People need to be able to selectively enable features, especially in
the use case where you want to include a particular language hack in
production code but don't need all the other magic melded in (and in
fact in a situation like that additional magic could be bad). If it's
a set of modules, I can map that to a hash, and then the user can just
pull out the elements they don't want.

I'll have to check into that but it could be the way to do it.

Anyway, those specs, that's very cool. I wouldn't have thought it was
even possible.

On 12/15/07, Tim Connor <timocratic at gmail.com> wrote:
> http://rubyforge.org/tracker/index.php?func=detail&aid=16334&group_id=4768&atid=18420
>
> Here is the pastie bit - might as well break it down into two pieces.
> Also, I fully fleshed out the specs for pastie before adding my little
> change, so I am toast for now - nothing like 80+ lines of specs for a
> 23 character change.
>
> This should also work as an example for how to spec/mock the editor
> piece.  It's way easier to deal with if you fully qualify the system
> calls with Kernel.system, btw (that took some head beating against
> desk until some caboose chaps gave the key tip).  Of course, it would
> have been even easier if Pastie was a full fleshed out module/class
> (something to keep in mind for avoiding the namespace issues for
> edit), but the first full spec out was definitely not the time to
> consider trying to re-architect against the project owner's wishes ;).
> _______________________________________________
> Utilitybelt-tinkering mailing list
> Utilitybelt-tinkering at rubyforge.org
> http://rubyforge.org/mailman/listinfo/utilitybelt-tinkering
>


-- 
Giles Bowkett

Podcast: http://hollywoodgrit.blogspot.com
Blog: http://gilesbowkett.blogspot.com
Portfolio: http://www.gilesgoatboy.org
Tumblelog: http://giles.tumblr.com


More information about the Utilitybelt-tinkering mailing list