Issue Type: Patch Created: 2007-12-14T10:32:00.000+0000 Last Updated: 2009-08-12T01:39:15.000+0000 Status: Resolved Fix version(s): Reporter: Lars Strojny (lars) Assignee: Rob Allen (rob) Tags: - Zend_Config
Related issues: - ZF-3474
Attachments: - 000-type-detection-zend_config.diff
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.
Posted by Lars Strojny (lars) on 2007-12-14T10:32:47.000+0000
Type detection for Zend_Config
Posted by Lars Strojny (lars) on 2007-12-14T10:33:21.000+0000
Related unit testcase
Posted by Lars Strojny (lars) on 2007-12-17T01:01:16.000+0000
Support for Zend_Config_Xml and Zend_Config_Ini. Unit test case missing.
Posted by Lars Strojny (lars) on 2007-12-17T01:05:55.000+0000
Another patch which is a) compatible against the latest trunk and b) removes the tabs used, sorry
Posted by Rob Allen (rob) on 2007-12-17T04:04:37.000+0000
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.
Posted by Lars Strojny (lars) on 2007-12-17T05:56:29.000+0000
My employer is happy with that. I've already signed one. So I will make Veit Bartels sign one too.
Posted by Rob Allen (rob) on 2007-12-18T13:46:29.000+0000
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?
Posted by Lars Strojny (lars) on 2007-12-19T04:44:40.000+0000
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:
<pre class="highlight"> MyFrontController::getInstance() ->setParam('disableOutputBuffering', !$this->_config->controller->front->buffer) ->throwExceptions($this->_config->controller->front->exceptions) ->returnResponse(true) ->addModuleDirectory($this->_config->controller->modules);
Posted by Lars Strojny (lars) on 2007-12-19T04:49:27.000+0000
Modified patch against the latest trunk
Posted by Rob Allen (rob) on 2007-12-19T07:01:44.000+0000
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.
Posted by Darby Felton (darby) on 2007-12-19T08:44:10.000+0000
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.
Posted by Lars Strojny (lars) on 2007-12-19T08:58:06.000+0000
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
<pre class="highlight"> 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.
Posted by Darby Felton (darby) on 2007-12-19T09:18:40.000+0000
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?
Posted by Lars Strojny (lars) on 2007-12-20T08:02:44.000+0000
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.
Posted by Rob Allen (rob) on 2008-01-27T14:43:56.000+0000
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?
Posted by Lars Strojny (lars) on 2008-01-27T15:49:05.000+0000
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.
Posted by Darby Felton (darby) on 2008-03-10T13:17:54.000+0000
I suggest that a proposal be written to further explore our options on such automatic casting behaviors.
Posted by Rob Allen (rob) on 2008-03-10T14:52:43.000+0000
Seems reasonable to me. I would like further input from minds better than mine.
Posted by Rob Allen (rob) on 2008-03-10T14:54:28.000+0000
This issue to go through as a proposal to enable more community input.
Posted by Wil Sinclair (wil) on 2008-12-17T13:56:50.000+0000
Did this proposal get authored/submitted? I'd like to make sure this is tracked somewhere before closing the issue.
Posted by Rob Allen (rob) on 2008-12-17T22:29:13.000+0000
As far as I know, no proposal has been created.
Posted by Robert Hänsel (r-o-b-e-r-t) on 2009-08-12T01:37:08.000+0000
Without automatic casting you have problems to build routes with regex
Posted by Robert Hänsel (r-o-b-e-r-t) on 2009-08-12T01:39:15.000+0000
Here the same problem
Have you found an issue?
See the Overview section for more details.