On Wed, Jun 9, 2010 at 12:08 PM, Lukas Kahwe Smith <m...@pooteeweet.org>wrote:
> > On 09.06.2010, at 12:01, André Rømcke wrote: > > > Example: > > function fetchById( int $id, bool $asObject = true ) > > > > If weak type hints are accepted, type hints would be useless in this case > as > > consumer can do something strange as fetchById( true, 'foo' ) (Obviously > I'm > > not saying anyone would do this intentionally, but in a large application > > you might not have full oversight and can unintentionally pass variables > of > > wrong type or in wrong order causing issues to surface much later as > there > > are no strict type checks that would detect the mistake immediately while > > developing). > > > please read RFC's you comment on (well the following was added to the RFC 2 > or maybe even 3 weeks ago): > in your above example there would be data loss in the type cast and > therefore there would not be silent auto casting. > > again there is only silent automatic casting being proposed in the case of > when there is no data loss: > "1" <=> 1 > > but "1abc" would not silently cast to 1 > > etc. > > anyway .. can we conclude this discussion? probably best if someone who is > more or less impartial would handle the call fore vote and figure out some > sensible way to let people vote on the various solutions that are proposed. > > First step would be to gather all of the ideas and rfcs, and create a comparsion between them. At this point, there are several proposals around in the wiki, some of them are old, and outdated, but Lukas did his best to merge/compare the weak and strict proposal at http://wiki.php.net/rfc/typecheckingstrictandweak There is another proposal by myself: http://wiki.php.net/rfc/splweaktypehintingwithautoboxing And I think there were discussions about extending the parser and adding support for the Reflection to allow handling the docblocks, but I think that was just a wild idea. So before we could vote, we should sum up the ideas. - strict OR weak type hinting? (define weak, what can be converted, what happens if cannot be converted, I think Lukas already did this) - core feature OR spl? (maybe both, see the error/exception part) - trigger_error OR exceptions? (we said, that exceptions shouldn't be allowed inside the core, so maybe this can be only impelemted through spl) - if we chose trigger_error, then E_NOTICE OR E_STRICT OR ??? on type/range missmatch we should gather the pros/cons for the comparsion. there were ideas about leaving out the type hinting for scalars, but adding new/extended functionalities to allow easier variable type/range check (maybe smarter func_get_args), etc. So my 2 cents: We should chose the *best* solution which makes *most* of us happy, but we should inspect every Idea, not just the ones that have pretty RFCs. Tyrael
