Hello Andrea, On 01.01.15 16:19, Andrea Faulds wrote: > I think it’d be weird to have different syntaxes for scalars and non-scalars. > We already use the syntax the RFC proposes in the PHP manual, and I don’t > think anyone’s confused by it.
I didn't meant to stay there's something wrong with the syntax, sorry if my text was confusing! I was rather trying to point out that it does not hint at anything but proactively tries to convert types; see below for more: >> 2. Casting and Validation Rules >> >> "While this RFC merely follows PHP's existing rules for scalar >> parameters, used by extension functions, these rules may not be familiar >> to all readers of this RFC." > > Yes and no. With the exception of hexadecimal numbers in strings, explicit > casts and internal functions follow the same rules for conversion. However, > the validation rules don’t match. Explicit casts never fail, while internal > functions will reject arguments that are non-scalar or don’t fit certain > rules. [...] > >> 3. "Non-numeric strings not accepted. Numeric strings with trailing >> characters are accepted, but produce a notice. " [...] >> What's the point of continuing the code when developer asked for "int" >> and code logic continues with "something not quite an int"? >> >> Doesn't that defeat the whole purpose of the use of this RFC? [...] > > I can’t say I love that behaviour either. It is, however, our existing > behaviour. I’d rather we be consistent with internal functions. And as you also pointed out: those conversion rules are different from what a plain "(int)$whatever" would do. I completely understand the technical ratio here: internal function have an existing argument/parsing system which is now exposed to the end developer ("php user") here. I argue this system is fit and works (and, err, talk BC; obviously!) for the whole internal PHP function/method system but .. .. does not reflect the needs and requirements of a php user/developer because exactly of these implicit conversion rules with three different output states (everything ok, hard type mismatch, notice on partial conversion). I'd also argue that scalar types in function signatures behaving differently than object type hints is potentially a bad thing for future of PHP and I already made my point which is the most important to me: >> What's the point of continuing the code when developer asked for "int" >> and code logic continues with "something not quite an int"? Now, going on step back here (talking about me), I'm speaking up because >my< needs are developer are different (mostly speaking about backend code, interfaces, libraries, frameworks) but OTOH I'm not a big known open source framework developer either ;) I would honestly be interested what the big framework/library players actually want/need; do they prefer this implicit scalar type conversion system or rather have a rigid system like the current object types but for scalars too? I think decision on this RFC should include also "their" saying too. It's complex because we can't force anyone to participate but I think above all these are the most important audience here because they know what they want and they know what their users want. I say this because usage of object types in PHP is almost non-existent (or, there are just too few cases) compared to the architecture of some of the framework/library systems out there. Hmm. thanks, - Markus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php