To Callback...or not to callback

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

Post Reply
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

To Callback...or not to callback

Post 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 :)
User avatar
Oren
DevNet Resident
Posts: 1640
Joined: Fri Apr 07, 2006 5:13 am
Location: Israel

Post by Oren »

Not sure I understand the situation completely, but I'd definitely go with #2.
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post 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.
User avatar
John Cartwright
Site Admin
Posts: 11470
Joined: Tue Dec 23, 2003 2:10 am
Location: Toronto
Contact:

Post by John Cartwright »

#2 for sure
User avatar
feyd
Neighborhood Spidermoddy
Posts: 31559
Joined: Mon Mar 29, 2004 3:24 pm
Location: Bothell, Washington, USA

Post 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.
User avatar
stereofrog
Forum Contributor
Posts: 386
Joined: Mon Dec 04, 2006 6:10 am

Re: To Callback...or not to callback

Post 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".
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post 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.
(#10850)
User avatar
vigge89
Forum Regular
Posts: 875
Joined: Wed Jul 30, 2003 3:29 am
Location: Sweden

Post 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 ;)
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Re: To Callback...or not to callback

Post 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
Post Reply