Re: Rack must not dictate how to create a middleware

Sys Ppp wrote:
>> I see you are using a module instance variable here. This is fine except 
>> that it limits you to only using the same middleware once.
> 
> Such is indeed I meant cases where middleware have to be a singleton. Or 
> when mixing is intensively used instead of classes. In other cases 
> surely using of classes is the best choice. Of course. But Builder must 
> not make any limitations for using singletons or any "classless" objects 
> there they are needed.

Why "must" it not? It makes the 99% usage case simple, where the 
middleware is an object containing an instance variable, and the 
constructor is passed the next module in the chain. If you want to have 
a Module as middleware, then you just construct it by hand.

> There are some non-classic OOP paradigms, by the way intensively being 
> used in Ruby, as I see. Such "classless" things as mixings, singletons, 
> interfaces and so on. They are very useful, when the quantity of 
> differences in object structures is near the quantity of these objects. 
> On startup stages of project, when at the fist look it is very hard to 
> deside which classes we have to make, but it is cleary known what kind 
> of objects we are need. It especially relates to such muddy things as 
> controllers in MVC pattern.
> 
> And invoking of method :new inside Builder's :use - it is bad 
> resctiction IMO.

If this "restriction" were removed, it would make Builder much harder to 
use. And that would defeat the point of Builder entirely.

With current Builder you just write:

use M1
use M2
use M3
run App

The whole point is that it encapsulates the following pattern for you:

a = App.new
b = M3.new(a)
c = M2.new(b)
d = M1.new(c)
run d

i.e. each request is handled by M1, then passed to M2, then passed to 
M3, then passed to the App.

If this is not the pattern you want, then don't use 'use' - combine the 
objects in whatever other way makes sense to you.
-- 
Posted via http://www.ruby-forum.com/.