ZF-2312: Automatic primitive type detection for Zend_Config

Description

The following patch adds support for type detection in the Zend_Config class. (string)"1.2" is casted to (float)1.2, (string)"1" to (int)1, (string)"true" to (bool)true and (string)"false" to (bool)false. It is implemented as an opt-in option so it does not break the API. The code was done by Veit Bartels, one of my co-workers. He did that for our company which has allowed me to provide ZF patches. If it is required he would be able to sign a CLA.

Comments

Type detection for Zend_Config

Related unit testcase

Support for Zend_Config_Xml and Zend_Config_Ini. Unit test case missing.

Another patch which is a) compatible against the latest trunk and b) removes the tabs used, sorry

Hi,

I haven't looked at the patches and won't until CLA is sorted out. You also need to check if your employer is happy to contribute and I suspect that the project may need a CLA from them too. Darby could probably tell you more.

Regards,

Rob...

My employer is happy with that. I've already signed one. So I will make Veit Bartels sign one too.

Hi,

I've given the basic concept some thought and have discussed with Darby a little. What exactly is the benefit of making Zend_Config primitive type aware? i.e. what use-case is this code solving?

Regards,

Rob...

It is a convenience feature. When setting exceptions wheither exceptions are thrown in the front controller I just pass the plain configuration value (configuration is verified before against as XML schema therefore I'm sure the value exists) without headaches about types. I just want to avoid that the code is full of casts because my developers are not sure which type it is. So casting the value once is much cheaper for us. Here is a code example where I use type detected Zend_Config:


            MyFrontController::getInstance()
                ->setParam('disableOutputBuffering', !$this->_config->controller->front->buffer)
                ->throwExceptions($this->_config->controller->front->exceptions)
                ->returnResponse(true)
                ->addModuleDirectory($this->_config->controller->modules);

Modified patch against the latest trunk

I'm not sure why you need to cast as !"0" will result in boolean true anyway as PHP will auto-cast appropriately.

In general, it's very rare to have to worry about casting. One of the few cases I can think of is dealing with strings within SimpleXML elements.

Regards,

Rob...

I have to agree with Rob at this point, as it has not been demonstrated to my satisfaction that such a typecasting feature is necessary.

So if you take a config file like snippet 0 it is much worse readable then false. But you are right, the exception example in the code above is bad, because the value is casted implicitly because of the negation. But think on


FrontController::getInstance()
  ->throwExceptions($config->throwExceptions);
  ->dispatch();

This will just not work. I have to sprinkle casts all over in my sourcecode instead of doing the business where it belongs: in the object which returns the data. The biggest problem with types and the config components is, that various adapters have various behaviours. This is really not the idea of adapters. Accessing an adapter through a front object should always provide the same behaviour independent of the used adapter. This is not the case for Zend_Config and our type detection is a way to fix that.

Well, these are good points, especially the one that Zend_Config should behave the same ways for different configuration storage formats. We do have to consider backward compatibility, and changing this behavior is certainly not backward-compatible (e.g., a "false" value in XML resulting in boolean false differs from current behavior).

I suspect that the way to resolve this issue is with a proposal that unifies the behaviors across various adapters, and we could probably break some backward compatibility in ZF 2.0.0.

Rob, what do you think?

I would suggest adding this patch in the 1.x branch because it is optional anyway. Later on we can adjust Zend_Config to convert types per default.

The trouble is that it adds additional baggage to the class and I don't see enough of a use-case to justify it. The functionality could probably be done quite easily as a subclass that implements it's own __get(). Are there really enough uses for type-casted config data that it should be in the core component?

At the end it is a design decision. The Zend Framework tends to be strict or at least stricter on types than a number of other component libraries so I would stress, that adding type detection is a good idea.

I suggest that a proposal be written to further explore our options on such automatic casting behaviors.

Seems reasonable to me. I would like further input from minds better than mine.

This issue to go through as a proposal to enable more community input.

Did this proposal get authored/submitted? I'd like to make sure this is tracked somewhere before closing the issue.

As far as I know, no proposal has been created.

Without automatic casting you have problems to build routes with regex

Here the same problem