3 ms·

I think what the GP might be trying to get at is this: you've reinvented partial function application and first-class functions. An instance of a class can be

I think what the GP might be trying to get at is this: you've reinvented partial function application and first-class functions. An instance of a class can be regarded as a bundle of functions which all have the constructor's parameters partially applied. If your instance only has one method, it's equivalent to a single, partially applied function. In that sense, what you've done is found a way to reorganise a Rails app in a very functional way - and, if you want to do that, given that Ruby doesn't have first-class functions or partial application (well, without proc hack, anyway), this may be the best way to do it. It may work very well, but it's at least as functional as it is OO.

stiff 14y ago
From the examples it doesn't even look like a _partial_ function application since it is not clear whether you can control how those services/policies/responders are initialized. Also I think it would be quite awkward for one service to initialize another and call it, so it is not really functional programming either, since there are no direct function calls. Since all the flow of the data is described in the routes file, it isn't OO at all and mostly reassembles dataflow programming as I said: http://en.wikipedia.org/wiki/Dataflow_programming http://en.wikipedia.org/wiki/Dataflow_programming Parts of this approach might be valuable, as I tried to emphasize, but as a whole this doesn't look good for plenty of reasons mentioned in the thread.
- regularfry 14y ago
  The CurrentUserResolver example in the README shows that some initialisation control is possible here. > it is not really functional programming either, since there are no direct function calls. There don't have to be. The classes and instances are being referred to by the developer in the same way as any first-class functions defined elsewhere would be - they're actually resolved and called by the framework. > Since all the flow of the data is described in the routes file, it isn't OO at all and mostly reassembles dataflow programming as I said It certainly is OO. There are instances, and they receive and act on messages. Yes, there's a dataflow-like DSL for routing, but that's not to the exclusion of other paradigms.
  - stiff 14y ago
    The CurrentUserResolver example in the README shows that some initialisation control is possible here. This is the dependency injection part, not the policy/service/responder core of the framework I am talking about. There don't have to be. The classes and instances are being referred to by the developer in the same way as any first-class functions defined elsewhere would be - they're actually resolved and called by the framework. I am not talking about what happens on the level of Ruby, I am talking about what happens logically at the level of the framework. The classes represent functions, sure, but they do not call other functions (services/policies/responders), the only "function-calling" is done by the router. Yes, this too is a form of functional programming, the form known as dataflow programming where the flow of the data is described explicitly. It certainly is OO. There are instances, and they receive and act on messages. Yes, there's a dataflow-like DSL for routing, but that's not to the exclusion of other paradigms. It isn't OO at the level of the framework. Yes, Ruby is underneath, there are classes, there are instances, and the thin ORM layer is object oriented, but the objects within the framework do not exchange messages, the only object doing all the message dispatch is the router. This is not OO, just look at the traits listed here: http://en.wikipedia.org/wiki/Object-oriented_programming http://en.wikipedia.org/wiki/Object-oriented_programming The framework basically forces you to abandon messaging (since there is no exchange of messages, just single directional messages flow from the router), abandon encapsulation (since the services have to access the data of the domain objects and hence the domain objects must make their data available to everyone) and abandon polymorphism (since the services are statically dispatched by the router). How can this be object oriented?
    - regularfry 14y ago
      > The framework basically forces you to abandon messaging (since there is no exchange of messages, just single directional messages flow from the router), The services receive messages from the router, then send messages to whatever they need to call to get the job done. Being sent messages by the framework is what makes it a framework and not a library; I don't get your objection here. > abandon encapsulation (since the services have to access the data of the domain objects and hence the domain objects must make their data available to everyone) Only if you're conflating domain objects with persistence objects. > and abandon polymorphism (since the services are statically dispatched by the router). They're statically dispatched on a constant name, not on a class. If you need polymorphism at that point, it's trivial to define a dynamic service resolver - all you need is something with a #new method assigned to the constant to do whatever late binding you want.

stiff 14y ago

From the examples it doesn't even look like a _partial_ function application since it is not clear whether you can control how those services/policies/responders are initialized. Also I think it would be quite awkward for one service to initialize another and call it, so it is not really functional programming either, since there are no direct function calls. Since all the flow of the data is described in the routes file, it isn't OO at all and mostly reassembles dataflow programming as I said: http://en.wikipedia.org/wiki/Dataflow_programming http://en.wikipedia.org/wiki/Dataflow_programming Parts of this approach might be valuable, as I tried to emphasize, but as a whole this doesn't look good for plenty of reasons mentioned in the thread.

regularfry 14y ago
The CurrentUserResolver example in the README shows that some initialisation control is possible here. > it is not really functional programming either, since there are no direct function calls. There don't have to be. The classes and instances are being referred to by the developer in the same way as any first-class functions defined elsewhere would be - they're actually resolved and called by the framework. > Since all the flow of the data is described in the routes file, it isn't OO at all and mostly reassembles dataflow programming as I said It certainly is OO. There are instances, and they receive and act on messages. Yes, there's a dataflow-like DSL for routing, but that's not to the exclusion of other paradigms.
- stiff 14y ago
  The CurrentUserResolver example in the README shows that some initialisation control is possible here. This is the dependency injection part, not the policy/service/responder core of the framework I am talking about. There don't have to be. The classes and instances are being referred to by the developer in the same way as any first-class functions defined elsewhere would be - they're actually resolved and called by the framework. I am not talking about what happens on the level of Ruby, I am talking about what happens logically at the level of the framework. The classes represent functions, sure, but they do not call other functions (services/policies/responders), the only "function-calling" is done by the router. Yes, this too is a form of functional programming, the form known as dataflow programming where the flow of the data is described explicitly. It certainly is OO. There are instances, and they receive and act on messages. Yes, there's a dataflow-like DSL for routing, but that's not to the exclusion of other paradigms. It isn't OO at the level of the framework. Yes, Ruby is underneath, there are classes, there are instances, and the thin ORM layer is object oriented, but the objects within the framework do not exchange messages, the only object doing all the message dispatch is the router. This is not OO, just look at the traits listed here: http://en.wikipedia.org/wiki/Object-oriented_programming http://en.wikipedia.org/wiki/Object-oriented_programming The framework basically forces you to abandon messaging (since there is no exchange of messages, just single directional messages flow from the router), abandon encapsulation (since the services have to access the data of the domain objects and hence the domain objects must make their data available to everyone) and abandon polymorphism (since the services are statically dispatched by the router). How can this be object oriented?
  - regularfry 14y ago
    > The framework basically forces you to abandon messaging (since there is no exchange of messages, just single directional messages flow from the router), The services receive messages from the router, then send messages to whatever they need to call to get the job done. Being sent messages by the framework is what makes it a framework and not a library; I don't get your objection here. > abandon encapsulation (since the services have to access the data of the domain objects and hence the domain objects must make their data available to everyone) Only if you're conflating domain objects with persistence objects. > and abandon polymorphism (since the services are statically dispatched by the router). They're statically dispatched on a constant name, not on a class. If you need polymorphism at that point, it's trivial to define a dynamic service resolver - all you need is something with a #new method assigned to the constant to do whatever late binding you want.