On Fri, Mar 9, 2012 at 3:32 AM, Anthony Ferrara ircmax...@gmail.com wrote:
Hey all,
As promised, I've created a POC patch to implement scalar type hints,
the way that zend_parse_parameters handles hinting. First off, here's
the patch:
Thanks for all the hard work you're putting into this :)
Hi, all
At first, many thanks to Anthony for writing the code!
2012/3/9 Anthony Ferrara ircmax...@gmail.com
fooi(1.5); // int(1)
Here an E_NOTICE would be a minimum as we are modifying the data. I'd
like to see an E_RECOVERABLE_ERROR as well. You should use
float-casting instead if you want to
Overall good job. I would prefer it a little stricter like people already
mention, but it's a step forward definitively with witch I'm totally fine
to live with.
On Fri, 09 Mar 2012 03:58:52 +0100, Ilia Alshanetsky i...@prohost.org
wrote:
My concern with this type of patch is that what you are proposing are
not really hints, they are forced casts. As such they modify the data
potentially leading to data loss.
Yes. Just like what happens with
Am 09.03.2012 09:42, schrieb Gustavo Lopes:
That said, I think we could move to a mild BC breaking change for
php-next that would make zpp stricter (with or without user-land
scalar type hinting/coercion).
A big +1 from me for this change.
--
PHP Internals - PHP Runtime Development Mailing
Am 09.03.2012 09:41, schrieb Arvids Godjuks:
Overall good job. I would prefer it a little stricter like people
already
mention, but it's a step forward definitively with witch I'm totally
fine
to live with.
Same from me. Good job.
--
PHP Internals - PHP Runtime Development Mailing List
To
I like it.
(Now, it would be nice to have another RFC about custom object casting to
int, float and bool...)
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/3/9 Anthony Ferrara ircmax...@gmail.com
Hey all,
As promised, I've created a POC patch to implement scalar type hints,
the way that
On Sun, Mar 4, 2012 at 00:28, Kris Craig kris.cr...@gmail.com wrote:
Lol well personally I disagree. I was super-stoked when the RFC process
was introduced and I would LOVE to see us make more use of it! Not only
does it help get a clearer guage of vote totals, but it also forces
proposals
hi Hannes,
RFC are good and now very well adopted way to propose new things to
the PHP project. We know that you don't like them, as it prevents one
to block or randomly veto new stuff or changes, but this is a good
move for the PHP project. Look at the 5.4 features, most of them have
been
(Now, it would be nice to have another RFC about custom object casting to
int, float and bool...)
You mean like https://wiki.php.net/rfc/object_cast_to_types which is
still in draft?
Note that __toBool would be problematic, since it would be called if
the object was used in an if statement,
(Now, it would be nice to have another RFC about custom object casting
to int, float and bool...)
You mean like https://wiki.php.net/rfc/object_cast_to_types which is still in
draft?
Note that __toBool would be problematic, since it would be called if the
object was used in an if
John,
And yet, __toBool probably sits right next to __toArray in terms of the level
of usefulness (maybe even beats it.) isset() can always be used to determine
whether something was ACTUALLY set to a non-null value, and to some extent
there is already a semantic problem anyway since
Yes, like that, only better. Since automatic type casting is central in
PHP, as this is evident after all this discussion, I believe that it should
be better supported. There are two thinks that I would like to see here:
1. No more magic methods, please.
2. It should cover (eventually) casting to
2012/3/9 Lazare Inepologlou linep...@gmail.com
Yes, like that, only better. Since automatic type casting is central in
PHP, as this is evident after all this discussion, I believe that it
should
be better supported. There are two thinks that I would like to see here:
1. No more magic
Lazare,
On Fri, Mar 9, 2012 at 8:54 AM, Lazare Inepologlou linep...@gmail.com wrote:
Yes, like that, only better. Since automatic type casting is central in PHP,
as this is evident after all this discussion, I believe that it should be
better supported. There are two thinks that I would like
What other types (except from other classes)...
I was talking about other classes... Of course, this does not have to be
implemented right now, but the syntax should not close the door for
something like that in the future.
If the magic is useful, why not add the ability?
Because it is ugly
What the current idea would be is an implicit casting (as I understood it
right).
Yes, exactly.
This won't make it easy passing a variable as reference.
Type casting combined with passing by reference is problematic in many
ways. Just an example:
fuction foo( string $buffer) { ... }
foo(
2012/3/9 Lazare Inepologlou linep...@gmail.com
Type casting combined with passing by reference is problematic in many ways.
Just an example:
fuction foo( string $buffer) { ... }
foo( $my_buffer );
Here, $my_buffer has just been declared, so it is null. Should this be an
error? I don't
From: Simon Schick [mailto:simonsimc...@googlemail.com]
2012/3/9 Lazare Inepologlou linep...@gmail.com
Type casting combined with passing by reference is problematic in many
ways. Just an example:
fuction foo( string $buffer) { ... } foo( $my_buffer );
Here, $my_buffer has just
what if we added extra out and inout hints for references?
With the danger of becoming boring, I have to say that C# also support
ref and out arguments... Are we reinventing the wheel here?
To be honest, this is going too far. Can we have the basics first? Passing
by reference is a corner
Lazare,
This won't make it easy passing a variable as reference.
Type casting combined with passing by reference is problematic in many ways.
No it's not. The core functionality does it quite fine, and it uses
typed parameters...
Just an example:
fuction foo( string $buffer) { ... }
John,
The reason you have to validate the input type in this case is because even
though it is a reference, we don't ACTALLY know that it isn't supposed to
contain an input (even though that would be against all sane rules most of
the time).
Well, we don't know, but I'd argue do we really
To be honest, this is going too far. Can we have the basics first? Passing by
reference is a corner case, at least for PHP.
RFCs die on ignored corner cases. IMO it's worth at least considering whether
there is a viable solution. The most common cases would be resolved easily if
we always
On 9 Mar, 2012, at 11:20 PM, Lazare Inepologlou linep...@gmail.com wrote:
Type casting combined with passing by reference is problematic in many
ways. Just an example:
fuction foo( string $buffer) { ... }
foo( $my_buffer );
Here, $my_buffer has just been declared, so it is null. Should
24 matches
Mail list logo
