Why should a string or array which can be changed by the user be implemented as constant ??

This is unlogical.

Please see the class constructor. Those are not values which can be changed by the user, they are array keys that are passed to the constructor via a config object and used to init the instance. Since the keys are exposed to the public api they should be constants.

You are wrong... the user CAN change these values.

Simply by giving

new Zend_Filter_StripTags(array('allowTags' => 'myTag'));

Having constants is useless as the user can then not change the value

new Zend_Filter_StripTags(array('allowTags' => CONSTANT));

We would even not know what to set as constant.
This is really useless in my eyes.

You are misunderstanding me. The keys themselves should be constants ... for example

new Zend_Filter_StripTags(array(Zend_Filter_StripTags::ALLOW_TAGS => object, Zend_Filter_StripTags::ALLOW_ATTRIBS => object));

Within the class constructor, the constants should also be used, not the hardcoded strings which are currently used.

First:
Where would be the benefit of a 34 chars long constant over a 9 char long string? I see no benefit... it's even more complicated in my eyes.

Second:
ALL filters and validators must have the same using. This means that when such a feature has to be implemented (I see still no benefit) it must be implemented for ALL and not only for a single one.

1.
The length of an identifier has no relation to its appropriateness or it's complexity. The benefit is that I can reference the constant from anywhere in my app without having to worry about the string or if the string will change in future versions of the app. Let's say I misspell the string as 'allowTagss' - NO error will be thrown, my object won't be constructed properly, and it will be a bitch to debug. However, if I were to misspell the constant Zend_Filter_StripTags::ALLOW_TAGSS, I'm going to get an error and can properly debug my app.

2.
I don't understand what you are saying here. It isn't even valid english. Also, this specific constant would have to be implemented only for this specific class, because it is used as a config key for this class only. There are many other points in the framework where the strategy I'm suggesting is used - e.g. Zend_Db_Table_Abstract.

Just to reiterate the value of this issue, try the following:

$filter = new Zend_Filter_StripTags(array('allowTagss' => 'div'));
Zend_Debug::dump($filter->getTagsAllowed());

You will receive no output and no error. Imagine how annoying it would be to debug something like this.

On the other hand, imagine:

$filter = new Zend_Filter_StripTags(array(Zend_Filter_StripTags::ALLOW_TAGSS => 'div'));
Zend_Debug::dump($filter->getTagsAllowed());

You will get something like - Fatal error: Undefined class constant 'ALLOW_TAGSS'

I'm sorry that you have problems to understand me.

But more than 70% of the worldwide population are no native english people, including me.

When I say "All filters have to behave the same way" then I mean that a feature must be implemented within all filters and not only in one and not in others. We are speaking here of usability which means in this case that the usecase for one filter should be equal to all others.

For example do all filters support a Zend_Config object as input.

No problem regarding the English, but to think that "a feature must be implemented within all filters and not only in one and not in others" or that "a usecase for one filter should be equal to all others", is simply wrong. One of the primary principles of OOP is to create unique classes that encapsulate their own logic. Within ZF, the only requirement for filters is that they implement Zend_Filter_Interface. All other features or implementations exist on a class-by-class basis.

In regard to your question - "do all filters support a Zend_Config object as input" - the answer is NO, which should have immediately proved to you that your assumptions about all or non were incorrect.

I have already outlined a valid usecase for this improvement, so I'm going to leave it at that. Maybe you should reassign this.

Thanks.

I think you don't understand what I am trying to say.

Think of the following:
A user want to use the StripTags filter and he uses the outlined constants.
In addition he wants to use the StringTrim filter. But here he can not use the constants, as only the StripTags filter implements this feature.
This is a break of usability. He would of course ask why this single filter behaves different than all other which are available.

Also to mention: Just because there are official requirements for custom filters, does not mean that the core filters don't have more requirements.

This has nothing to do with OOP principles but simply with the fact that when features are common available the user has more benefit, needs less time to learn and so on.

Btw: All core filters accept a Zend_Config object... that some filters don't have a constructor does not negotate this rule.

And I see no reason why I should reassign issues for the components which I maintain. Having a discussion to get behind the rationale of a issue is part of the process of resolving or closing it.

I just discussed this feature with other core developers.

We will not include this feature for Zend_Filter.
Reasons behind this decission:

• The keys are documented or will be documented soon (I am working on this since 2 weeks)
• All options are also defined by a setter and getter methods. So debugging is not problematic
• The keys themself are verbose... they are no numbers. So there is no reason to have a constant
• Using constants would increase typing

Therefor this issue will be closed as won't fix.

This is going to be my last response to you. I urge that if you don't reassign this issue, you at least run it by someone else who speaks better English.

That said, what does using the StripTags filter have to do with using the StringTrim filter? Answer = NOTHING - THEY ARE TWO SEPARATE CLASSES WITH TWO SEPARATE GOALS! Your argument here makes NO sense at all.

Again, I've outlined a valid use case for this improvement which in no way breaks usability or goes against the core goals of Zend_Filter. Do what you want. At this point, I don't care. It's a small improvement anyway. You have been incredibly difficult to deal with.

As already said I requested other opinions within the development team.

But when no one from 40 ZF core developers wants this feature to be implemented I would say it's a unique decission. I got only negative responses on your feature request.

And just because you don't understand what simplicity and usability means for ZF and their users does not mean that ZF does not follow this rules.

You may not recognised it, but all core filters have the same way of handling them... if this is how options can be given, how a filter behaves on failures or also which getters and setters are available... all core filters behave the same way.

As with all core components you are free to extend them to provide your own additional features.

I wrote that response at the same time you wrote yours. If you had looked you would have seen that. Again, I don't care if you implement it or not. This is an open source project, and I was giving my opinion on a suggested improvement. Next time I will just keep it to myself.

Your behavior has been completely unprofessional. Perhaps you should not be working on open source.

As far as I see, thomas actually replied pretty professional. He didn't think it was necessary (or even good) to implement the improvement you were suggesting, and he gave some arguments on why it shouldn't be implemented.

Also, he asked other developers (including me) for an opinion on this issue, and we all agreed that this is something that we should not implement at all.

Another thing: Thomas has made lots of good contributions to the Zend Framework. And without him, ZF would not be what it is today.