On 2012-03-02, Anthony Ferrara ircmax...@gmail.com wrote:
Well, there are a few questions about the implementation:
1. *Which* type casting rules should it follow?
a. Regular cast rules (like $foo = (int) $foo), where it converts
always without error?
b. Internal function cast rules, where
Matthew,
Have you seen the new thread and RFC around this?
https://wiki.php.net/rfc/parameter_type_casting_hints
I went with option A, as I see erroring on cast as a more general
problem. So for consistency, I implemented it exactly like normal
explicit casts...
Anthony
On Mon, Mar 5, 2012 at
Anthony,
I still don't like the null-as-a-default-value solution. I find it
confusing.
I know that something similar appears in class type hinting, but:
1. Class type hinting does not do casting (yet).
2. Apart from null, no other value could be placed anyway. (Even that is a
little bit wrong as
Hi, Lazare
In your examples you are accessing an maybe non-existing array-key.
This will raise an E_NOTICE. See the note below this example:
http://php.net/manual/en/language.types.array.php#example-85
Maybe you also want something like that:
isset($x) ? (is_null($x) ? null : (int)$x) : null
In your examples you are accessing an maybe non-existing array-key
Yes, this is why I used the error silencing (@) operator. But anyway, it is
irrelevant to the whole proposal.
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/3/5 Simon Schick simonsimc...@googlemail.com
Hi, Lazare
In your
Hi, Lazare
Sorry, I've only looked at your first array-example :)
Bye
Simon
2012/3/5 Lazare Inepologlou linep...@gmail.com
In your examples you are accessing an maybe non-existing array-key
Yes, this is why I used the error silencing (@) operator. But anyway, it
is irrelevant to the
Hi Lazare,
I'm a bit divided on your proposal.
On one hand I kind of like the simplicity of the syntax and the basic
idea behind it:
(int?) $x
which should be strictly translated to the following, without any way to
change that behavior by any type casting overload system:
is_null($x) ?
This could be usefull for other instances as (string null) or (bool
null) as well... Your thoughts?
Typo! The examples should read (string unset) and (bool unset)
BTW: Order would equal what is type casted OR simply accepted!
~ Daniel Macedo
--
PHP Internals - PHP Runtime Development
Hi Daniel,
No, it is not inspired from the short ternary operator. It's a rather
common conversion. C# has a similar notion of nullable types (with totally
different mechanics however). By the way, in this particular area PHP's
type system is more sound than that of C#, because null is not just a
Sorry, I used unset in the same way type casting works, not as in
unset() ... Common gotcha: http://php.net/unset#example-4824
Here's how the manual refers to it:
http://php.net/type-juggling
(int), (integer) - cast to integer
(bool), (boolean) - cast to boolean
(float), (double), (real) - cast
Hi, Anthony
At first, thanks for your great work!
As I have to learn C and C++ from scratch it was quite a good help to have
someone like you pushing it forwards.
I like having the casting exactly in the definition of the function, even
if it just saves the 6 characters. You have all information
To be honest, I'm not as sold on this version (I built it as a POC, but to
see how useful it is). It feels like it's not doing enough. All it really
does is save 6 characters.
Personally, I think it saves much more characters (,,,in the
documentation).
And I think, that's enough. Nothing
+1 for the syntax. There are two nice side effects I would like to
underline.
1.
Error-raising can be clearly delegated to the type juggling mechanism.
There will be no need to implement anything new here but reuse the existing
type juggling system of PHP. That would be very consistent. At the
Well, there are a few questions about the implementation:
1. *Which* type casting rules should it follow?
a. Regular cast rules (like $foo = (int) $foo), where it converts
always without error?
b. Internal function cast rules, where it warnings on error and
prevents execution of the function.
c.
On Fri, Mar 2, 2012 at 7:51 AM, Anthony Ferrara ircmax...@gmail.com wrote:
Well, there are a few questions about the implementation:
1. *Which* type casting rules should it follow?
a. Regular cast rules (like $foo = (int) $foo), where it converts
always without error?
b. Internal function
Hey all,
Here's a much more robust and updated patch (actually, it seems good
to go to me, but needs significant review)...
https://gist.github.com/1963999
One potential issue is that it requires an API change to
zend_verify_arg_type (which appears to only be called in zend_vm_def.h
- and by
Hey all,
I know given all the discussion about this topic lately, this is a hot
topic. But I whipped together a quick POC patch to implement scalar
type casting for function parameters. Let me describe it:
Patch: https://gist.github.com/1947259
Example:
function foo( (int) $bar ) {
I can't comment on the internal implementation, but I like the use of
the casting syntax. It's not as pretty, but make the intent clear, and
there's not BC issues with class names.
David
On 02/03/12 14:48, Anthony Ferrara wrote:
Hey all,
I know given all the discussion about this topic
Whoops, I linked to the wrong gist... Here's the proper one:
https://gist.github.com/1955338
On Thu, Mar 1, 2012 at 11:32 PM, David Muir davidkm...@gmail.com wrote:
I can't comment on the internal implementation, but I like the use of
the casting syntax. It's not as pretty, but make the
I do like retaining the same functional behavior afforded to internal functions.
Cast syntax seems awkward to me though. Some things that immediately come to
mind:
// ?? lossless, but wrong type. Does this cast or fail?
(function((object)$o){})(array());
// ?? If (object) is allowed, (array)
Anthony Ferrara wrote:
foo(1); // int(1)
foo(1); // int(1)
foo(1.5); // int(1)
foo(foo); // E_RECOVERABLE_ERROR - Expected integer
foo(array()); // E_RECOVERABLE_ERROR
Double-checking, but this is different to normal typecasting, isn't it?
If so, it might be a bit confusing using the
Ryan McCue wrote:
Double-checking, but this is different to normal typecasting, isn't it?
If so, it might be a bit confusing using the typecasting syntax.
Could have sworn I saw that 123foo would give E_RECOVERABLE_ERROR, but
I can't find that now, so possibly disregard this.
--
Ryan McCue
22 matches
Mail list logo
