camping/camping — Issue #54: Figure out a better implementation of Camping.goes
Author: MatmaRex
Created: 2012-01-17 18:16:07+00:00
State: open
Labels: Future

I mean, `gsub`-bing on and `eval`-ing Camping's own source code? There just has to be a less braindead way.

What we have leads to ugly stack traces and forces every extension to Camping to do even worse things - not only evaling its own code in `Camping` module and all apps that might have been already created, but also modifying the "source-string" that is kept around.

Isn't it possible to maybe `dup` the module and all of its "submodules"? Maybe `Camping.goes` could create a new, empty module and `include Camping` into it? Maybe we could make `Camping` a class and have everything inherit from it? Just food for though, I haven't tried any one of these, really.

(We could also just drop the idea of multiple apps, but I feel that'd be too much - they're a pretty nice thing.)

(The motivation for this issue is that I recently suggested someone Camping as a Ruby web framework, and somebody else complained about, I'll cite, "meta-recursive bootstrapping process that practically breaks your brain"), and I had to think hard about some reasoning as to why we do that.

(Related to #10)