Comments on: Chain of Functions http://nodename.com/blog/2005/07/19/functionchain/ Sun, 22 Aug 2010 03:17:40 -0600 hourly 1 http://wordpress.org/?v=3.0 By: Alan Shaw http://nodename.com/blog/2005/07/19/functionchain/comment-page-1/#comment-12 Alan Shaw Tue, 19 Jul 2005 22:03:45 +0000 http://nodename.com/blog/?p=3#comment-12 Tony, I'm not sure what you're referring to as the wrapping class or the child item, so I may be mistaking your meaning, but I believe you're criticizing only one thing: the ability to dynamically alter a member function of an object. As you know, I'm not providing that; it's there in ActionScript already. But yes, it does raise some concerns, as you yourself wrote about just today in your post <a href="http://teknision.blogspot.com/2005/07/delegatesbe-careful.html">Delegates, be careful...</a>. I'll summarize if I may: First, you show that Delegate.create(someObject, someFunction) is inherently dangerous for the very reason that "if for some reason someFunction is overwritten at runtime (which is common in AS) then your delegate no longer refers to the correct function." So the Delegate would then not work correctly, and furthermore it would waste memory because the old version of someFunction would have been garbage-collected if your Delegate wasn't still holding a reference to it. You propose a version of Delegate that uses a String name of the function rather than a Function reference. This will always resolve to the current version of the member function. Sounds good to me. (A little slower, though, I expect.) <br /> (Then you speak about potential problems Delegate can cause in the EventDispatcher context -- also quite interesting, but I don't think dynamic functions is relevant to that.) <br /> But I thought your complaint in your blog was not with dynamic assignment of functions -- that's a given in ActionScript -- but with the implementation of Delegate in such an environment. Or as my uncle used to say about crossing the street in New York City, "You got to be careful." <br /> Is there some way my FunctionChain makes the problem worse? Tony, I’m not sure what you’re referring to as the wrapping class or the child item, so I may be mistaking your meaning, but I believe you’re criticizing only one thing: the ability to dynamically alter a member function of an object. As you know, I’m not providing that; it’s there in ActionScript already. But yes, it does raise some concerns, as you yourself wrote about just today in your post Delegates, be careful…. I’ll summarize if I may: First, you show that Delegate.create(someObject, someFunction) is inherently dangerous for the very reason that "if for some reason someFunction is overwritten at runtime (which is common in AS) then your delegate no longer refers to the correct function." So the Delegate would then not work correctly, and furthermore it would waste memory because the old version of someFunction would have been garbage-collected if your Delegate wasn’t still holding a reference to it. You propose a version of Delegate that uses a String name of the function rather than a Function reference. This will always resolve to the current version of the member function. Sounds good to me. (A little slower, though, I expect.)

(Then you speak about potential problems Delegate can cause in the EventDispatcher context — also quite interesting, but I don’t think dynamic functions is relevant to that.)

But I thought your complaint in your blog was not with dynamic assignment of functions — that’s a given in ActionScript — but with the implementation of Delegate in such an environment. Or as my uncle used to say about crossing the street in New York City, "You got to be careful."

Is there some way my FunctionChain makes the problem worse?

]]> By: Tony MacDonell http://nodename.com/blog/2005/07/19/functionchain/comment-page-1/#comment-11 Tony MacDonell Tue, 19 Jul 2005 16:58:04 +0000 http://nodename.com/blog/?p=3#comment-11 Even though this is a neat class, I question the type of architectural patterns that it's usage will lead to. It is neat to be able to simulate/reformat a function at runtime, but here's the issues I see arising: 1/ Readability of code. If this was used extensively in a project, following the bootstrapping of the code becomes extremely difficult. In large OO projects it can sometimes be difficult anyways, but this adds yet another level of abstraction at the class level. To me it seems as though you are trying to deprecate the idea of a class level method with this, and that is something that architecturally is very dangerous as it is a fundamental aspect of OOP. The wrapping class owns the task that the child item's onRelease method is triggering, and a Delegate or Proxy should be there for the sole purpose of sending notification of that event. Using your class you are breaking down that ownership to the point that you invalidate the wrapping class's presence in the architecture. It does not own the process anymore, an abstract object does instead. 2/ Inheritance, Sublassing and overwriting tossed out the window. If one was to again use this extensively in a project, Subclassing would become a nightmare. The fact that you are trying to make dynamic methods means that classes that utilize this would be nearly impossible to subclass. Just some thoughts and criticisms, but I do see it's cool factor though. Even though this is a neat class, I question the type of architectural patterns that it’s usage will lead to.

It is neat to be able to simulate/reformat a function at runtime, but here’s the issues I see arising:

1/ Readability of code.

If this was used extensively in a project, following the bootstrapping of the code becomes extremely difficult. In large OO projects it can sometimes be difficult anyways, but this adds yet another level of abstraction at the class level.

To me it seems as though you are trying to deprecate the idea of a class level method with this, and that is something that architecturally is very dangerous as it is a fundamental aspect of OOP.

The wrapping class owns the task that the child item’s onRelease method is triggering, and a Delegate or Proxy should be there for the sole purpose of sending notification of that event.

Using your class you are breaking down that ownership to the point that you invalidate the wrapping class’s presence in the architecture. It does not own the process anymore, an abstract object does instead.

2/ Inheritance, Sublassing and overwriting tossed out the window.

If one was to again use this extensively in a project, Subclassing would become a nightmare. The fact that you are trying to make dynamic methods means that classes that utilize this would be nearly impossible to subclass.

Just some thoughts and criticisms, but I do see it’s cool factor though.

]]>