Re: Rack must not dictate how to create a middleware

Brian Candler wrote:
> Sys Ppp wrote:
>> But Builder must not make any limitations for using singletons or any "classless" objects there they are needed.
> 
> Why "must" it not?

Why must objects be created by Builder and not be created outside?
The answer of this questions I have done in the first post. Besause in 
the
first case it will be a coupling, but in the second it will be cohesion. 
You
cau decide by youself, what you like more.

> 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.

Simplicity of usage is necessary but not sufficiently for well project 
design.

> If you want to have a Module as middleware, then you just construct it by hand.

What do mean saying "by hand"? Classes usually also is constructed "by
hand", in common way. But in case of modules you always may use mixing.

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

Why do you think what difficulty of usage will be certainly caused just 
by
removing this restriction?

> With current Builder you just write:
> 
> use M1
> use M2
> use M3
> run App
> 
I also want to write so.
use a
use b
use c
run d

But I want what these objects would be precreated and (kind_of? 
ChainMember)
== true. Rather than they have to be some classes, which must create 
chain
objects. This exactly is cohesion vs. coupling.

> Anyway, there's nothing magic about the method 'new'. You could write:
> .......
> That is, you can make your code conform to the middleware API simply by 
> implementing a 'new' method which sets the next app in the chain, and 
> returns the object to be called.

This is excellent technical solution based on some technical conditions. 
I was waiting what you would have suggested it.

But it is the ugly hack at the semantic look.
It conflicts with the principle of least astonishment. If something has 
the
:new method, then something.kind_of? Class == true.

Thus in searching of solution we get either semantic hack of Builder 
(see my
1st post) or semantic hack of Ruby. Why? The answer is in bad design of 
Builder.

> You can make a wrapper for this pattern if you are using it frequently.

If it is needed to invent wrappers for making something more clear, it 
is
better to primary make something more clear.

> But I still assert that middleware written as a singleton is pretty 
> useless. The whole point of Rack is that you can have a complex 
> branching tree of request handling, and each node in the tree "knows" 
> where to forward the request next. Having a node which can only ever 
> forward to one place makes it impossible to plug in somewhere else. I 
> cannot think of any realistic example where this makes sense.
> 
> Certainly there may be middleware objects which share some underlying 
> singleton object (e.g. a logger), but the middleware object itself 
> should not be a singleton, because it's responsible for storing the next 
> hop.

Are singletons useful or not. May I use one singleton in several nodes 
of
middleware tree, or may I use several singletons only one per one node. 
How
to better make middlewares, as instances, as modules, as procs, or as 
some
objects else. These are all my owns desiners's problems. And I do not 
want,
what the Builder decides instead of me, how can I do it.

And IMO this is not a good solution to delegate to Builder creation of 
chained
objects.
-- 
Posted via http://www.ruby-forum.com/.