Hi! > This is pretty horrible and should be fixed by making sure that
I don't see why it's so horrible. In fact, handling null is easier than handling exception (and faster too, probably). Many functions that try to create objects return null or false when unable to. Of course, we could change it by introducing exceptions to core, but I don't see why do it peacemeal then. > constructors either return an object or throw an exception. > Additionally the exception policy for core (that was previously > discussed here: http://marc.info/?t=119263748000001&r=1&w=2 ) should > be updated so that any constructor returning NULL is considered a bug, > no matter what the ini settings are. To be clear, procedural code > should behave as before, with users expected to check for errors. > This would be a BC break for people who are handling the constructor > returning null currently, as they would need to wrap that code with an > try/catch block. That means the same failure of collator construction now needs to be handled in two different ways. > Constructors give warning, but are then in an unusable state > ------------------------------------------------------------ > Several constructors check the parameters that they are given.....and > then just give a warning when they are not acceptable. e.g. These should be fixed to either return null or throw exception, but the behavior should be unified for everybody. > Again, this should be fixed by changing the constructors to throw an > exception if the input parameters are not acceptable. The next question would be - if the ctors throw an exceptions, why factory methods shouldn't? They are doing the same work essentially. > Constructor gives error > ----------------------- > > Some constructors check the parameters they are given, and then emit > either a 'Catchable fatal error' error or other error e.g. This is even bigger can of worms. If we wrote PHP today from scratch, catchable fatal errors would be exceptions. But they are not, so we need to deal with it - by either leaving them as is, or converting them all together. > > <?php > $foo = new IntlGregorianCalendar(new StdClass); > //Output: Catchable fatal error: Object of class stdClass could not be > converted to string in.. This is not property of the ctor, it's property of parameter handling. I.e. if you do it for IntlGregorianCalendar, you should do it for every class that gets incompatible parameters. And probably user-space funcs too since there's no reason for them to behave differently. I actually wouldn't mind that, but this is yet bigger can of worms as it requires refactoring a lot of assumptions on how parameters are parsed. > i) Can anyone see a big hurdle in fixing these behaviours, other than > it being a BC break for people who are currently relying on these > behaviours ? Yes. The first hurdle is to understand which of these behaviors need fixing, and how, which you seem to dismiss as obvious but it's really not. The second is to do it in consistent manner so it doesn't again come out as part of the functions do one thing, another part another, and third part something else different. > ii) Are there any other bad behaviours that people are aware of that > ought to be fixed at a major version? I think we have enough for now to discuss here, so if we want do discuss other behaviors better to open separate thread. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
