Figure out a better implementation of Camping.goes

[camping]

Figure out a better implementation of Camping.goes

[Bluebie]

When I first saw this thread I thought I'd be all for tearing it to pieces and redoing it all smoothed over and shiny on the inside. I've been persuaded by @judofyr's arguments. I say keep the origami! It's very fun ^_^

Ditch origami and ditch multiple apps? To that I say we don't need to reinvent Sinatra. Go use Sinatra! It's great! Really! :)

I love the crazy hacks camping does, and I couldn't care less about (eval). My only concern is that this framework is often appealing to people starting out coding via it's relationship with hackety hack, try ruby, and the poignant guide. I wish we could find room in our clockwork hearts for a bit of input validation here and there. Raise exceptions, instead of exploding tiny gears everywhere! Javascript frameworks have similar issues - they are also optimised to be compact though to a lesser extent than camping. When camping goes bad, debugging isn't fun. I'd love to see us fill up that extra kilobyte with some friendly bits for beginners and just a couple of really useful new features. To hell with this 3kb madness!

Notably javascript frameworks also ship with unabridged versions (uncompressed in js terminology) which are used during development, then apps are deployed with the compressed version. Perhaps our unabridged version could include some helpful input validation which isn't included in the real camping? Sort of training wheels for debugging? With good errors origami wouldn't matter nearly so much.

Camping extension API could be fun. Especially if it used that ruby-parser stuff to extract the proc and read the source string right out of the ruby code. @MatmaRex Do you think you could play with making this API using ruby-parser's proc extraction things? If you get something working, put it up as a gem, and we could see about integrating it and using that as the means through which ar and mab are injected on demand. Sound good?

[judofyr]

https://github.com/camping/camping/blob/master/extras/images/latl.png:

Some do not understand Camping and lash out with spears reaching 4 to 6 feet in length.

Or as a wise man once said to me:

No, let's not have rules. I don't feel comfortable with having
coding standards or any protocol on Camping. The point of Camping
is to have very ugly, tricky code that goes against all the rules that
people make for "beautiful" code these days. To show that ugly code
can do beautiful things, maybe.

I don't want to demonize anyone here, I just want to express the
ideas that make Camping different. Camping's personality is 80x50.
It is like the little gears of a watch that are all meshed together
into a tight little mind-bending machine. The challenge of Camping
isn't to figure out how to automate obfuscation. The challenge is
to bring new tricks into the code that push Ruby's parser and make
everyone look twice.

Not all code needs to be a factory, some of it can just be origami.

[judofyr]

On a technical note, I would say:

• "Fixing" it while preserving the current behavior won't be easy. At least not under 4k.
• We can make the exceptions say "camping.rb" instead of "(eval)"
• If you don't like the gsub-ing, you can just use the Camping-module. Add a Camping::Apps << Camping and the reloader will work as well.

[MatmaRex]

The thing is, it's difficult to adjust an already created piece of origami to be something a little different. So while anyone can appreciate an origami, only experts can devise new designs and improvements.

In non-metaphorical words, you really shouldn't have to work hard just to add a method or two to some web framework. Camping is already confusing enough with the few modules - Camping itself, Helpers, Views, Controllers - which apparently all include each other. (When I started out with Ruby and Camping, I remember I would have to spend some time just to find a method definition in the unabridged code.)

Camping might have been perfect for _why when he created it, but a lot has changed since then, both in Ruby, its ecosystem and Camping itself.

Back to the point. The .goes-related code is the only bit of Camping that really irks me. It just feel unclear, impure, to commit such heinous acts with otherwise so beautiful code. All the other hacks and little crazinesses can be understood with the available comments, basic knowledge of Ruby syntax and a couple of minutes each; the mind-bending mystery of Camping.goes and friends requires deeper knowledge and more time. (Again, I remember reading the code of camping/mab.rb for the first time, and thinking "what the hell is that".)

I know I can use Camping module itself, but this sort of defeats the ability to create and run multiple apps, which Camping people seem to be fond of. (And I am too.)

[MatmaRex]

And for a change something constructive for me, instead of a rant.

Could we at least define some sort of API for extending Camping? We could define a little method on Camping and every submodule, say .extension, that would accept an (optional, maybe) extension name, and a block to be evaluated in context of a given module, and also in contexts of respective modules of every app created until then, and every app that is still to be created. This could possibly be optional - to use an extension in the app, you would have to use another method, but I can't think of an intuitive name - extend and use are already taken (although we might add this to the latter).

We could avoid mangling Camping::S this way, while keeping the current behavior, and probably even a fragile compatibility (not that it's not fragile right now...) with old extensions, if there are any. The list of loaded extensions could be available somewhere.

So you could for example do this:

[camping/mab.rb]

require 'markaby'

Camping.extension 'mab' do
  module Mab
    include ::Mab::Mixin::HTML5
    include Views

    alias << text!

    def mab_done(tag)
      h=tag.attributes
      [:href,:action,:src].map{|a|h[a]&&=self/h[a]}
    end
  end
end

And that would be it, the entire file.

[judofyr]

As I said in #10: I think Mab and ActiveRecord are special. They are a part of Camping. Why should other extension need to do the same? Why can't they just be included?

[judofyr]

As for your example, this wouldn't work.

Constants are defined/looked up in lexical context:

[1] pry(main)> d = proc { module Foo; end }
=> #<Proc:0x007fa28c935dd8@(pry):1>
[2] pry(main)> Module.new.class_eval(&d)
=> nil
[3] pry(main)> Foo
=> Foo

---

There are really two issues here:

1. It's hard to define methods/classes in Camping which propagates down to all the apps (because there is no inheritance)
2. It's hard to figure out where to define things

1 is something I don't think is required for anything else than Mab, ActiveRecord or whatever we would consider to be a part of Camping.

2 is something that's difficult for anyone who doesn't fully understand how the modules work together (that's not Camping specific; you have the same issue in any complex project). This is something we should fix with documentation IMO:

Controllers is for storing your controller classes
Models is for storing your model classes
Views is for storing Mab/Markaby views
Helpers is for storing the methods you can use in your controllers and views
Base is the internal Camping-module for storing methods you can use in your controllers
Camping is included in your controllers, so you can override Base-stuff and still call super

Now, I do agree that Helpers and Base are kinda solving the same stuff. Maybe we should move all the helpers into Base and say that Helpers is an empty module for you? (Just like Controllers, Models and Views)?

In addition, both Helpers and Camping serves as overridables for Base-stuff:

module App
  def service(*args)
    @headers['Content-Type'] = 'application/json'
    super # if we overwrote App::Base#service, we have no place to call super
  end
end

If we change the include-order, we can make the same thing possible in Helpers. But I kinda like that Helpers is for stuff you use in your controllers and views, while Camping (or YourApp) is where you override specific behavior to your app… Hm…