configuration: constants vs singleton pattern

[akrabat]

that don't involve OO bloat

OOI, what do you define as OO bloat?

The basic wrapping code is:

class InputFilter
{
    protected $inputData= NULL;

    public function __construct(&$inputData)
    {
        $this->inputData= $inputData;
        $inputData = NULL;
    }

    // input filtering functions like getAlpha() etc follow here 
} 

I've not bothered including the input filtering functions as they would have to be written as either getAlpha($var) or Obj::getAlpha(). The fundamental code in either case is identical.

I'd have thought that the security of knowing that you can't use tainted data through laziness would be worth the bloat of less than 10 lines of code?

*shrug*

One thing that I am keen on doing in my apps in general is making the safer way the easiest way. PHP doesn't necessarily help on input with it's superglobals and it doen't help on output with the echo command not escaping automatically...

[akrabat]

A bit presumptuous, perhaps?

Zend_Filter doesn't or you can pass false as the second argument to Zend_InputFilter's constructor to stop it doing that.

There's also Zend_InputFilter::getRaw() available so you can pick up the original data, but have to explicitly choose to do it.

[McGruff]

As mentioned, one very good reason to encapsulate input is to create an input gateway. This promotes security by providing a safe, single entry point. Nothing is allowed through if it doesn't pass the validation rules. It also helps make it easy to switch the app to a command line context. The rest of the app doesn't need to know by what means the input has arrived.

The whole point of OOP is encapsulation. GPC data may be needed by several parts of the app but they aren't needed everywhere. It's better if they're only passed where needed. That's not PAD bigotry that's basic OO theory.

[McGruff]

A bit presumptuous, perhaps?

I've been meaning to ask how they echo back invalid user input in a redisplayed form...

[Snaily]

I'd have thought that the security of knowing that you can't use tainted data through laziness would be worth the bloat of less than 10 lines of code?

I edited my previous post to respond to what you said before (but maybe you didn't see it)...I don't think in general wrapping $_POST is code bloat, as the wrapper ends up doing a lot of work (i.e validation) On the other hand I think wrapping all superglobals is more often than not OO bloat. Also I don't have a rigid definition of "OO code bloat" for you, but often when you find yourself using many wrappers...that don't do anything but protect something etc, that is a good indication. One of the nice things about PHP in my mind is that you can write OO code where it makes sense and procedural code where it makes sense....its unfortunate with PHP5 that this is being lost in some sense.

[Selkirk]

Its a lot of work on EACH request to..allocate 4+ objects, populate them and unset the original source.

Um, no it isn't.

[Snaily]

The whole point of OOP is encapsulation. GPC data may be needed by several parts of the app but they aren't needed everywhere. It's better if they're only passed where needed. That's not PAD bigotry that's basic OO theory.

I don't think the "whole point" of OOP is encapsulation, but regardless its better in what sense? Because you don't trust yourself or someone in your development team? This is clearly one way of looking at matters...one that is rejected flat out by other communities (ahem perl). Also my point was not to argue against OOP (I just get sick of people pretending its the only way to do things), rather to point out that PHP at its core is not OOP based. If strict OOP is important to you why in the world would you use PHP?

[McGruff]

One of the nice things about PHP in my mind is that you can write OO code where it makes sense and procedural code where it makes sense

I've been through OOP v procedural debates too many times to remember. The only constant theme is that it always - always - turns out that the anti-OOP brigade do not have enough experience of OOP to criticise it properly (and none at all of testing). People who should be asking questions and learning instead take up positions which they cannot defend. I'd actually quite like to have this discussion some day with someone who does but for the moment I'll just say that procedural code makes no sense at all to me, if we're talking about web apps written in php.

PS: don't worry thr it won't be long till you're 21

[Dr Livingston]

Snaily,

You have the impression I feel that to create objects in the sense of PHP uses a lot of resources, and therefore has performance implications?

That is not the case, in fact it's the opposite, in the way that PHP and it's environment works - everything is destroyed at the end - that actually makes PHP a more flexible choice for web development

Someone else made the comment recently that those who are new to PHP and object oriented programming - with PHP - have that mindset, that you need to count on their fingers the number of objects to create, for 'best performance' is what I take away from your posts.

> its unfortunate with PHP5 that this is being lost in some sense.

That's progress, and before you denounce that as progress, the entire software industry for the most part nowadays is developing OO so there can't be anything bad about that, and as for bloat, now and again I get a bit bloated, usually after a curry and a few beers...

[thr]

PS: don't worry thr it won't be long till you're 21

If you're pointing at the leagal age to drink, drive, etc. it's 18 where I live, not 21 but it's not far from 21.. no

[McGruff]

I don't think the "whole point" of OOP is encapsulation

What do you see it as being?

... regardless its better in what sense?

    $input->getFoo() 

... means that I don't eg access a raw $_POST['foo'] throughout the app. Instead I'll pass $input (or just the validated value) where it's needed. If I want to make a command line version of the app very little needs to be changed - everything is calling on $input not POST.

    $input->hasBadSyntax() 

..means I might not even get that far. Code carrying out key/value validation and interpreting those results does, I think, result in some good, cohesive classes (there would be a whole pile of objects co-operating to achieve this).

[Snaily]

I've been through OOP v procedural debates too many times to remember. The only constant theme is that it always - always - turns out that the anti-OOP brigade do not have enough experience of OOP to criticise it properly (and none at all of testing).

I'm sure you feel that way....being from the "OOP brigade". Please note, I never critized OOP.

People who should be asking questions and learning instead take up positions which they cannot defend. I'd actually quite like to have this discussion some day with someone who does

I have worked with procedural, OOP and functional languages for years. Please safe this sort of rubbish for someone you actually know about ok?

I'll just say that procedural code makes no sense at all to me, if we're talking about web apps written in php.

Right...no bigotry...geez. This says a lot about your knowledge of procedural programming languages.

Interesting how every post in PAD where someone goes against the official dogma....grows into this sort of nonsense.

[Viflux]

Snaily, this makes two threads where you've completely commandeered the discussion and turned it into a language/philosophy debate.

If you hate the discussions here, why are you here?

[Snaily]

Snaily, this makes two threads where you've completely commandeered the discussion and turned it into a language/philosophy debate.

I made one comment...the comment is attacked because it is not of the offical dogma. This is how things work in communities like this... I get the same rubbish when I say something good about PHP in a java community (try it one day!).

[Dr Livingston]

> Please note, I never critized OOP.

You have actually, you've said that basically all it is is bloat, and thus without any more thought to the matter, there is no point of it.

> If you hate the discussions here, why are you here?

Could be anyone guess really...

[McGruff]

I made one comment...the comment is attacked because it is not of the offical dogma. This is how things work in communities like this...

You're right the discussion here shouldn't merely be blinkered dogma. I'm quite happy to explore the reasoning behind any statements I've made. But you need to do more than simply accuse people of being dogmatic now. You need to dismantle the arguments.

[Snaily]

You have actually, you've said that basically all it is is bloat, and thus without any more thought to the matter, there is no point of it.

Your glasses a little foggy? I said "wrapping all superglobals tends to be OO code bloat", this does not translate into a universal critique of OOP. Furthermore...its almost comic that I'm being painted as some anti-OOP guy as I've been mostly developing in Java for the last 3-4 years.

You need to dismantle the arguments.

Coming from a guy that insults someone's knowlede they know nothing about....err. Additionally my disagreement was with thr, that was ended. The rest of this is the PAD gang coming to his defense...with the typical group-think.

[McGruff]

I think it's fair to challenge statements in a technical discussion. Also to question if an individual is qualified to comment in the first place. It's not an easy subject and people who do often aren't. Comments about OOP being inefficient or that the php way is to only use objects where there's good reason to come across as naive. It's not my intention to insult you (and you're not doing too bad a job yourself with some frank appraisals of other posters).

So, now that we've introduced ourselves, we can move on to a more detailed technical discussion, if you like?

[auricle]

I've been through OOP v procedural debates too many times to remember. The only constant theme is that it always - always - turns out that the anti-OOP brigade do not have enough experience of OOP to criticise it properly (and none at all of testing).

I'm one of those with little experience, yet I've come to love OOP (reading the code excerpts on the regular PHP forum here is really painful now). So I hesitate to respond to someone with McGruff's credentials

Snaily may correct me if I'm wrong, but I sense that his (her?) comment was about "degree". If I may present an example, in Selkirk's CRUD example in WACT...

$Front = new PathInfoDispatchController();
$Front->addChild('index',   new Handle('IndexPage', APP_LIB_ROOT . 'phpmodule/index.page.php'));
$Front->addChild('details', new Handle('DetailsPage', APP_LIB_ROOT . 'phpmodule/details.page.php'));
$Front->addChild('delete',  new Handle('DeletePage', APP_LIB_ROOT . 'phpmodule/delete.page.php'));
$Front->addChild('edit',    new Handle('EditPage', APP_LIB_ROOT . 'phpmodule/edit.page.php'));
$Front->addChild('add',     new Handle('AddPage', APP_LIB_ROOT . 'phpmodule/add.page.php'));
$Front->setDefaultChild('index');
$Front->start(); 

Add each child in turn (there's a sniff of the procedural about this, even though those objects don't immediately do anything). Should Selkirk have created a class called CrudApplication and wrapped all of this in it?

$crud = new CrudApplication();
$crud->execute(); 

Where would you draw the line?

I tend to see the greatest benefit of OOP as being organisation. One might have to dive in and out of lots of files to follow the action (as it were), but it sure is easier to inspect a class method than to scroll a couple of hundred lines to see where a variable might have been set. Lastcraft has frequently alluded to the "expressiveness" of OOP, provided one names objects sensibly. Is this partly what those from a computer science background mean by "encapsulation" or is it simply separation of concerns?

I think it's fair to challenge statements in a technical discussion. Also to question if an individual is qualified to comment in the first place. It's not an easy subject and people who do often aren't.

Well, that would be me again. But if I make such uninformed statements and someone like McGruff makes a counter-argument, I may be disabused of whatever silly notion I expressed. So McGruff may bemoan the airing of certain prejudices, but the potential for greater understanding or exploration of issues always exists.

[McGruff]

I hesitate to respond to someone with McGruff's credentials

I wouldn't claim to have credentials . I've still got a lot to learn and I don't have any published code. It would also have to stand up to peer review.

the potential for greater understanding or exploration of issues always exists

That's what it's all about. We have to trust each other enough to criticise each others' opinions. I don't mind being proved wrong: it means I just learned something new.

I think I'm carrying some bruises from one too many OOP v procedural discussions. The experience of those contributing is usually extremely relevant and shows in the way they talk about code. I don't agree with Snailly's comments about OOP validation, or the place of OOP in php, but I apologise if I was wrong to lump you in with the "anti-OOP brigade".

[auricle]

I apologise if I was wrong to lump you in with the "anti-OOP brigade".

You didn't (and couldn't have, since, up to this point, I hadn't commented).

[McGruff]

Sorry I maybe wasn't very clear - that was meant for Snaily.

[Snaily]

Comments about OOP being inefficient or that the php way is to only use objects where there's good reason to come across as naive.

I never stated that OOP in general is inefficient (Although technically in PHP at least OO code is slower). I did suggest that one should not use OO based techniques in cases where there is no clear reason to...what is naive about this? PHP is not like .NET...or Java...its core is all procedural.

Is this partly what those from a computer science background mean by "encapsulation" or is it simply separation of concerns?

What you stated isn't really what is meant. Encapsulation refers to a few different related things, but the way its being used by people on this post is to refer to "information hidding". So you can create an object and keep all the details of its implemention hidden from users, as far as PHP goes this is really only possible with PHP5. Encapsulation isn't unique to OO though. In OO the unit of encapsulation is the object/package, in procedural code its the procedure/file, functional code its the function/structure. You can write complex application with either of these paradigms, I personally find that particular ones are more natural in some domains vs others. For example for GUIs I love OO...for things like parsers etc I like procedural or functional languages. In the case of the web...I don't think any paradigm is more natural. This is why I find it somewhat funny that people try to push all web related code into this OO box, particularly in a language like PHP which gives you the ability to use both procedural and OO programming.

[Tanus]

As long as you only use the Registr/SL/DI for getting your objects - of them does.

So in other words, none of them do, unless you're using the singleton to protect the creation of the object that goes into the collection . For me, this is important as I tend to fix a lot of broken code, so it's good to know that object X, which should be the same throughout the application, actually is X because the singleton has protected some simple development mistake.

Just as a point of curiosity, how do you control access to your Registry / SL / DI object? I tend to use a singleton for that... .

[Ren]

So in other words, none of them do, unless you're using the singleton to protect the creation of the object that goes into the collection . For me, this is important as I tend to fix a lot of broken code, so it's good to know that object X, which should be the same throughout the application, actually is X because the singleton has protected some simple development mistake.

Just as a point of curiosity, how do you control access to your Registry / SL / DI object? I tend to use a singleton for that... .

With my implementation of DI. You specify at component register time wether the DI should return the same object, or create new ones.

class Foo { }
class Bar { }

$container->registerComponent('Foo');
$container->registerCachedComponent('Bar');

// This will cause the container create new instances.
$foo = $container->getInstance('Foo');    

// But this will always return the same instance.      
$bar = $container->getInstance('Bar'); 

And for how I control access, I pass it around to things that need it.