Page 1 of 1

To Callback...or not to callback

Posted: Wed Jul 04, 2007 8:50 pm
by alex.barylski
Building on that disscussion of the battle of frameworks, etc... :P

I have the following issue:

I have a config object, highly specialized with no dependecy on anything. The main application engine uses it to initialize itself. The main engine also uses a global function which is used in several locations to translate an alias/handle into it's full form before actual processing.

I have just changed the architecture and the need has risen for me to use that very global function inside the config object. I'm shy to do so because I like keeping things simple and inpedenent of others.

Should I:

1) Just call the global explicitly (what happens if I change the name or need to add more namespace)???
2) Pass the function to the config object (through ctor) and have the config object use it as a callback

The latter offers the greatest flexibility, because I have a tecndancy to refactor code like crazy, especially changing function names, etc as better names come to mind. I also may one day wish to throw that function into an object/class (right now it's fine as a global) passing a function callback is an easy way to avoid having to conduct a Search and Replace whenever the namespace changes.

Go with number two or is there a different approach which would yield greater benefits?

If you decide to answer with anything other than #2 be verbose and obvious, clearly indicating pros and cons.

Edit: I'm just analyzing my architecture and thinking...there may be a requirement again in the future to provide a specialized object a callback functions. Different objects and more importantly, different callbacks. I always [s]try[/s] and keep any global initialization code, variables, function calls, etc inside the index.php file.

The engine object as we speak has the hardcoded global function named (as it's passed to config object) explicitly as a string passed to the config ctor(). If there are other objects, either composites of engine class, etc...that may require callbacks in the future I can see this technique being messy in a constantly changing namespace such as my own.

I'm wondering if it would make much sense to have a registry, specifically dedicated to global callbacks, so any namespace change can be applied inside my init.php once instead of having to grep the source and find each instance. Like a service locator almost, but not really...

Any related patterns or ideas or suggestions as to how to implement a more robust system?

Cheers :)

Posted: Thu Jul 05, 2007 12:37 am
by Oren
Not sure I understand the situation completely, but I'd definitely go with #2.

Posted: Thu Jul 05, 2007 2:41 am
by Maugrim_The_Reaper
#2 seems a better option. It also allows end users to override the default callback function should such a need arise.

Posted: Thu Jul 05, 2007 3:41 am
by John Cartwright
#2 for sure

Posted: Thu Jul 05, 2007 7:27 am
by feyd
Maugrim_The_Reaper wrote:#2 seems a better option. It also allows end users to override the default callback function should such a need arise.
Agreed. Composition is highly useful.

Re: To Callback...or not to callback

Posted: Thu Jul 05, 2007 7:41 am
by stereofrog
Hockey wrote: I have a config object, highly specialized with no dependecy on anything. The main application engine uses it to initialize itself. The main engine also uses a global function which is used in several locations to translate an alias/handle into it's full form before actual processing.

I have just changed the architecture and the need has risen for me to use that very global function inside the config object.
So, why don't you make that global function a part of config object?

First is bad because there's no such thing as "just function" in OOP.
Second is bad because we don't use callback functions in OOP, we use "callback objects" or "listeners".

Posted: Thu Jul 05, 2007 11:41 am
by Christopher
I agree with feyd and stereofrog, definitely #4. And I say that because you will probably not implement #3 properly because you are using a global.

Posted: Thu Jul 05, 2007 1:32 pm
by vigge89
arborint wrote:I agree with feyd and stereofrog, definitely #4. And I say that because you will probably not implement #3 properly because you are using a global.
Hmm, where did options #3 and #4 come from? :)
With my limited knowledge I'd say #2 along with previous posters ;)

Re: To Callback...or not to callback

Posted: Thu Jul 05, 2007 2:40 pm
by alex.barylski
stereofrog wrote:
Hockey wrote: I have a config object, highly specialized with no dependecy on anything. The main application engine uses it to initialize itself. The main engine also uses a global function which is used in several locations to translate an alias/handle into it's full form before actual processing.

I have just changed the architecture and the need has risen for me to use that very global function inside the config object.
So, why don't you make that global function a part of config object?

First is bad because there's no such thing as "just function" in OOP.

Second is bad because we don't use callback functions in OOP, we use "callback objects" or "listeners".
1) I was afraid someone would ask that and I would have to answer, it's a complex system composed of many discrete objects. Many of these objects *might* require the use of this global function, which is truely global in that it doesn't make sense in any of the classes, even the config class. So it's a global.

2) PHP is not a pure OOP language. So I will make use of functions when functions make sense. I just don't want the hardcoded function name (the arguments will never change) scattered through out my source - knowing my own habits; Functions and classes change names frequently as I refactor.

3) Again PHP != 100% OOP. I utilize OOP as required when it makes sense and procedural when it makes sense. The way it stands right now (I think I would know best seeing as I've designed the thing) this function doesn't make sense inside a class, it's really a support/helper function.

I don't believe in throwing miscellaneous functions into a Generic, Helper or Support type class consisting of static functions. I'd rather fake a namespace and use a global function. When the need arises, I will refactor that function into a class if it ever makes sense.
vigge89 wrote: Hmm, where did options #3 and #4 come from?
With my limited knowledge I'd say #2 along with previous posters
That what I was wondering. :P