I've always maintained that the key difference between an object and a component is granularity. Both can be reusable, but a component generally represents a (reusable) encapsulation of a conceptually larger "chunk" of logic/data than a typical object.
>> From: Leo Sutic [mailto:[EMAIL PROTECTED]] >> >> > From: Berin Loritsch [mailto:[EMAIL PROTECTED]] >> > >> > > From: Leo Sutic [mailto:[EMAIL PROTECTED]] >> > > >> > > Suppose you have a pool-max of 3: >> > > >> > > public void handleRequest () { >> > > someMethod (); >> > > someMethod (); >> > > someMethod (); >> > > someMethod (); >> > > } >> > >> > And this is different from the current state of affairs, how? >> > If a request requires 5 transformer instances, and you have >> > your pool max set to 3, you will still experience slow down. This >> > is no different than automatically releasing a component when the >> > request is handled. >> >> The difference is this - with explicit release I can: >> >> public void someMethod () { >> component = manager.lookup (ExpensiveButPooledComponent.ROLE); >> ... >> manager.release (component); <<<<<<<<<<<< Added this >> } >> >> And thus not drain the pool, as I only really need 1 instance. >> >> As for whether this is efficient or not - that is not the >> issue. The point is that with a per-request GC, you will need >> to lookup all components you require *at the start of the >> request* and then pass those around as you process the >> request (to avoid too many lookups) - >> unless you are really sure that you will not end up in a situation >> similar to the one I described. (That is, you repeatedly call >> a method that does a lookup during a single request. It will never be >> as simple as the example: someMethod() will call someOtherMethod and >> so on until, 20 steps up the call stack, you have a lookup. >> And then, 20 more steps until the last method returns.) > > Hmm. What we have here is a bad design. Should the container > make up for your poor design? Can you really get away with only > three instances in a pool with a web environment? Honestly, > there is nothing in Cocoon that does what you are talking about. > > You have something more than "I may want to implement this poor > design some day" that we can discuss? > > What you described here is woefully innefficient, and you will > have to refactor it completely in the very near future. Why not > discourage bad design? > > >> > I am finding more and more what people are calling components >> > are nothing more than Objects that observe the Bridge >> > pattern. They implement an interface, introduce a few >> > lifecycle methods, etc. If they are object then they should >> > be treated as such. >> >> Then what is a component? A Facade? > > A component is a reusable binary that observes a public interface. All > component implementations of a specific public interface are > interchangeable. The Bridge pattern states that the implementation > observes an external interface--you can't have components without > that. > > However, the most successful components "do", not "represent". > It's a conceptual thing. If you process a request by calling a > method on a component, then we are all good. If you have a component > represent something and call multiple method calls on it, then > we run into the problems we are experiencing. > > Now, a way to philisophically enforce the "do" vs. "represent" > concept is to call the components by a new name: services. A service > is a type of component that "does" something or performs a service. > > >> > If a pooled object requires an explicit >> > return to a pool, than that decision should be made in the >> > GeneratorManager, or the TransformerManager, etc. Not in the core >> > lookup mechanism. >> >> What you propose is then that pooling is removed from >> the container itself. Pooling will be done by first using a >> component manager to lookup another manager, and then use >> that manager to obtain an instance from the pool. Am I correct? > > That is one way of handling what you are talking about without > writing a GC routine. > > >> > > ...means a load of GC policy parameters for the client. >> > >> > ? I don't get this at all. >> >> I meant "user", not "client". My bad. > > It's still a container concern. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] -- "The heights of genius are only measurable by the depths of stupidity." --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
