Any objections to anonymous functions?

[Jason Knight]

I know for a fact that a future version of this is going to use anonymous functions for loading template components. They'll be added to an array where each entry will have the anonymous function of the template component, (or a printf string!) as well as pointers to the next anonymous function in a parameter "chain".

That'll make sense later.

But does anyone here have issues with the idea of my converting process and output routines to anonymous functions instead of polluting the namespace?

PHP even having anonymous functions is pretty new. I'm not certain of if it will introduce performance concerns or not -- it shouldn't but this is PHP after all.

It would greatly simplify the back-end logic if all process() routines

Likewise, perhaps $data should be a object with getters/setters? I'm... iffy about doing that. Would be nice to "force" the idea of "module name" separations instead of blindly hoping people use good naming conventions.

Just looking for arguments both for and against here. I'm really undecided.

Though the next big thing on my to-do list is a style guide for the codebase. Something I SHOULD have done at the start, but at the start I wasn't taking this as seriously as I really wasn't expecting so many of you to take it out for a run.

[benanamen]

Likewise, perhaps $data should be a object with getters/setters?

When I see getter/setter alarm bells go off and red flags start waving. If you are using getters/setters you are breaking encapsulation.

[Jason Knight]

When I see getter/setter alarm bells go off and red flags start waving. If you are using getters/setters you are breaking encapsulation.

The WHAT now?!? How is a technique that leverages the protections of encapsulation breaking it?!? that's a new idea to me.

Or are you only thinking strict encapsulation, and not data verification/access restriction? As in you don't use private and getters to create scoped read-only? (aka the data access level "parked" that PHP strangely lacks?)

Set validation, construction, and locking are all different "levels" of encapsulation; there's more to it than 100% private.

-- edit -- though I may have a different viewpoint on that coming from those years programming Ada. Seriously, can you explain in more detail why you think that way?