configuration: constants vs singleton pattern

[Snaily]

And for your knowledge all my _GET, _POST, _SESSION and _COOKIE, etc. data is wrapped in a nice object and then unset.

Both inefficient and a waste of time....

[thr]

Both inefficient and a waste of time....

Not realy, as the objects in question sanitize the variables and make sure they contain no invalild data, etc. And I'll have complete controll over what parts of my application that need the session/etc. data.

And "inefficient", that's like what 0.0000001 of total execution time or 0.00001% of a sql query. If you're going to critizise the way someone else does something, atleast give a valid argument... ignorance.. *sigh*

[Ren]

I think there are distinct advantages to wrapping the superglobals into an object.

• Testing, can mock the object, and thus test everything that uses them.
• Have to deal with configuration/enviroment issues, things like magic_quotes, and perhaps perform some normalization of $_SERVER across web server software (IIS/Apache/etc).

[Snaily]

And "inefficient", that's like what 0.0000001 of total execution time or 0.00001% of a sql query. If you're going to critizise the way someone else does something, atleast give a valid argument... ignorance.. *sigh*

The kids like to throw out words like "your ignorant" blah blah... I wasn't making an argument rather a statement. Futhermore your response is silly. This is a clear case of over-design..and what you are doing does not add a trivial amount of over head. Its a lot of work on EACH request to..allocate 4+ objects, populate them and unset the original source. One can give this sort of argument for every ineffiency "oh its just a coupe of milliseconds"...and by the time you're done your code is a bloated piece of junk.

And I'll have complete controll over what parts of my application that need the session/etc. data.

You have complete controll regardless...after you are the one writing the code.
Anyhow most of PHP's core is not object based....creating wrappers around it is pointless and highly inefficient and another language should be used if that is what is desired.

Testing, can mock the object, and thus test everything that uses them.

It certainly makes it easier...I dont' think its worth the performance cost.

[BerislavLopac]

Snaily, POITROAE...

[Snaily]

Snaily, POITROAE...

??????

[thr]

The kids like to throw out words like

I'd say it's only a kid who says someone else is a kid

(God, I shouldn't feed the trolls =/)

[Snaily]

I'd say it's only a kid who says someone else is a kid

Your birthday is in your profile...you ARE a kid. This is a fact.

God, I shouldn't feed the trolls =/

Please do ignore my posts in the future.

[Dr Livingston]

> Futhermore your response is silly. This is a clear case of over-design..

No it's not... It's called encapsulation

> creating wrappers around it is pointless and highly inefficient and another language should be used
> if that is what is desired.

As I said above, you gain encapsulation, also you gain a few other benifits; I think Ren spelled them out to you?

If you are going to come to the PAD forum and pick an arguement with someone then at least make sure you are well versed in the current methodologies, etc that we all practice in the forum, before you do so, as yes - you do come across as being ignorant.

[BerislavLopac]

Your birthday is in your profile...

Unlike yours... Should this tell us something?

[thr]

God, I shouldn't even dignify that post with an answer... starting to ***** about age now? sigh...

[DerelictMan]

Snaily, POITROAE...

??????

I think he meant: Premature Optimization Is The Root Of All Evil

[thr]

I think he meant: Premature Optimization Is The Root Of All Evil

100% serious I thought he was cursing in his own language(I noticed it says Zagreb, Croatia next to his name/pic ;p)

[dreamscape]

And for your knowledge all my _GET, _POST, _SESSION and _COOKIE, etc. data is wrapped in a nice object and then unset.

Well I could maybe see doing that if you come from another language and are more comfortable with its user input model, and wish to emulate it.

But in practice, I really fail to see how it is really any different than the idea of magic quotes. Both capture user input and perform some mass transformation on the captured user input. The idea on its surface is not too bad, but in practice it ends up creating more problems than it solves.

Real though, I think you're just being a bit too schizophrenic. [God I hope not, but no offense meant to anyone who actually suffers from schizophrenia]

[Snaily]

No it's not... It's called encapsulation

Encapsulation without benefit is a waste. Even the authors of PHP have warned against wrapping existing PHP libraries. People that try to make everything in PHP OO fail to see its stengths and should really be using another language.

If you are going to come to the PAD forum and pick an arguement with someone then at least make sure you are well versed in the current methodologies, etc that we all practice in the forum, before you do so, as yes - you do come across as being ignorant.

Oh boy this is classic. Yes....if one doesn't adhere to the PAD group-think one is ignorant! Its disgusting and makes posting on sitepoint undesirable when a small group of self-gratifying weinies feel the need to treat anybody that disagrees with them like crap. I have no interset in the PAD group-think, and I will continue to post what I feel (report my posts if you feel they violate some policy) otherwise if you don't like it...IGNORE IT.

[thr]

Well I could maybe see doing that if you come from another language and are more comfortable with its user input model, and wish to emulate it.

I don't want to emluate any type of user input model but I want to be sure that the input I get is clean and sanitized.

But in practice, I really fail to see how it is really any different than the idea of magic quotes.

What? To mention some things I use the wrappers for(which me and Ren already said):

• I have complete controll over what parts of my application that gets access to input data.
• Strip magic_quotes_gpc automaticly

These are by far the two most important ones, others are such as Ren said for testing purposes and I can also apply input filters on the objects if I want to apply specific regexp/other rules on the data.

Now tell me how's this anything like mq_gpc which just quotes everything?

Real though, I think you're just being a bit too schizophrenic.

That was uncalled for, realy stupid comment tbh...

[thr]

Encapsulation without benefit is a waste. Even the authors of PHP have warned against wrapping existing PHP libraries. People that try to make everything in PHP OO fail to see its stengths and should really be using another language.

Then tell me oh so aged god, how should it be done in your bible? Just leave the input data as it is, run "some_func_that_cleanas_them()" before I use them every time? Enlighten me/us, please.

[Shrike]

How about staying on topic and cutting down on the insults.

[BerislavLopac]

This is actually a simple problem.

If you have only data, with no behavior (methods) except for getting and setting, leave it in arrays. If there is some behavior, put it into objects.

In other words, thr has a point to move the superglobal data into objects if he does something with it (specifically, he validates it); now, whether all of this data warrant such treatment is a separate issue.

[Dr Livingston]

> Then tell me oh so aged god, how should it be done in your bible?

Oh mighty one... I want to be enlightened too.

[akrabat]

The Zend guys think wrapping $_POST into an object isn't a bad idea either:

From the manual:

"Zend_InputFilter sets the array that is passed ($_POST) to NULL, so direct access is no longer possible. (The raw data is only available through the getRaw() method, which is much easier to monitor and/or avoid altogether.)"

An example usage:

$filterPost = new Zend_InputFilter($_POST);
$alphaName = $filterPost->isAlpha('name');

if ($alphaName !== FALSE) {
    /* $alphaName contains only alphabetic characters. */
} else {
    /* $alphaName === FALSE */
} 

[Snaily]

Then tell me oh so aged god, how should it be done in your bible? Just leave the input data as it is, run "some_func_that_cleanas_them()" before I use them every time? Enlighten me/us, please.

Firstly you aren't doing a good job at ignoring my posts... Secondly I never suggested there is one way this should be done...rather I disagreed with:

And for your knowledge all my _GET, _POST, _SESSION and _COOKIE, etc. data is wrapped in a nice object and then unset.

Ahem...key word all. In some application this may make the most sense...but a lot (if not the majority) of applications there is absolutely no reason to do this, other than some silly aesthetically reasons. There are mutliple alternative ways of dealing with input validation...that don't involve OO bloat etc, I really don't feel the need to go over them in this thread.

The Zend guys think wrapping $_POST into an object isn't a bad idea either

The comment was about wrapping all superglobals not just post data, but $_POST is the one case where it more often than not makes sense to wrap it, as you usually need to validate it all anyways.

[Selkirk]

I think there are distinct advantages to wrapping the superglobals into an object.

I think this is an emerging best practice in PHP. The benefit of encapsulating access to the request input is improved security and easier security auditing, not to mention the potential for eliminating duplicate code.

[thr]

Firstly you aren't doing a good job at ignoring my posts... Secondly I never suggested there is one way this should be done...rather I disagreed with:

I never said I would ignore your posts, you said that... anyways...

Ahem...key word all. In some application this may make the most sense...but a lot (if not the majority) of applications there is absolutely no reason to do this, other than some silly aesthetically reasons. There are mutliple alternative ways of dealing with input validation...that don't involve OO bloat etc, I really don't feel the need to go over them in this thread.

Thanks, you supplied an argument instead of saying "that sucks" - Ok I'd agree not all applications need this, but if you're using some type of framework(ZF,m4,CI,Cake,Symfony, etc.) it usually helps alot as you can restrict access to the input - so not every action, command and module can go nuts(as in change them, etc.) on the input data.

[Selkirk]

Zend_InputFilter sets the array that is passed ($_POST) to NULL

A bit presumptuous, perhaps?