I should point out that returning false on param parsing failure on the
language level is one thing (not to mention it's not ok to do that in the
first place by my taste), but forcing that behavior on the user-land level
is kind'a too much.
Consider how the code will become much more complicated
Arvids,
On Mon, Mar 12, 2012 at 4:39 AM, Arvids Godjuks
arvids.godj...@gmail.com wrote:
I should point out that returning false on param parsing failure on the
language level is one thing (not to mention it's not ok to do that in the
first place by my taste), but forcing that behavior on the
What is consistent and exists on the internal language layer
not necessarily good for the user-land. I'm kind'a surprised no one
thought
of that.
As I said I can live with the throwing notices and warnings (and not
E_RECOVERABLE_ERROR as I personally wanted), but returning false even
Arvids,
Yea, that part looks confusing.
What I wanted to say is that I would like to get E_RECOVERABLE_ERROR and I
was voicing my opinion on that earlier in the threads. But I could live with
E_WARNING and E_NOTICE if community decides it to be less strict - I will
clean up my code not to
Hello Anthony,
I will raise once again the question about accepting null. According to
your POC, null is an acceptable value if it is also declared as a default
value. This is problematic for the scalar types, because they can very well
have a different default value.
An example: There is a
2012/3/12 Lazare Inepologlou linep...@gmail.com
function set_check_box_state( bool state = false ) { ... }
set_check_box_state( null ); // null will be converted to false here...
Therefore, this cannot work, unless the default value becomes null, which
is against the requirements. What I
I think that the null issue is not an issue. Strictly speaking if you
want null or an int - leave out the type hint and use generic argument that
will accept anything.
I think it's over-engineering to try and push a special treatment for the
null. If function/method argument accepts anything but a
Hello Simon,
First of all, none of your examples cover the case I mentioned, and so, my
concerns are still valid.
Secondly, you make some wrong assumptions about how this specific POC
works. For example, you write:
function foo(int $d = 20) { var_dump($d); }
foo(null); // This should then
I'm not sure about you, but I don't wanna see that kind of thing
eventually making it's way into the language
Me neither. All I am saying is that, since int|null is already here from
the back door, I think it should be properly supported.
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/3/12
2012/3/12 Lazare Inepologlou linep...@gmail.com
I'm not sure about you, but I don't wanna see that kind of thing
eventually making it's way into the language
Me neither. All I am saying is that, since int|null is already here from
the back door, I think it should be properly supported.
Lazare,
The patch of Anthony, clearly states that this is accepted:
function foo ( int $bar = null ) { }
And this is what I called an int|null.
Yup, it does. Because that's the current behavior with array and
object casting. If you default it to null in the declaration, null is
a valid
Hello Arvids,
The patch of Anthony, clearly states that this is accepted:
function foo ( int $bar = null ) { }
And this is what I called an int|null.
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/3/12 Arvids Godjuks arvids.godj...@gmail.com
2012/3/12 Lazare Inepologlou linep...@gmail.com
Thank you for the confirmation.
What I am saying here is that, although this behavior was fine for objects,
it is not enough for scalars. One of the main arguments in favor of the
adoption of this syntax was that null was the only possible default value
for objects anyway. This obviously is not
On Fri, March 9, 2012 2:51 am, Nikita Popov wrote:
On Fri, Mar 9, 2012 at 3:58 AM, Ilia Alshanetsky i...@prohost.org
wrote:
Anthony,
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
On Fri, March 9, 2012 5:58 pm, John Crenshaw wrote:
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).
Last
On 2012-03-12, Arvids Godjuks arvids.godj...@gmail.com wrote:
--f46d0442880e02b97f04bb0b432b
Content-Type: text/plain; charset=UTF-8
I think that the null issue is not an issue. Strictly speaking if you
want null or an int - leave out the type hint and use generic argument that
will accept
Ok, so it looks like we've had some decent conversation, but it has
started to tail off a bit. I'd normally draft an RFC at this point,
but it seems there's still some contention on how exactly the
implementation should work.
Personally, if we're going to go for any form of strict checking
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
(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
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:
Directly apply-able without re2c:
https://gist.github.com/2004623
Removing generated files (requires re2c to compile):
Anthony,
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.
On Thu, Mar 8, 2012 at 9:32 PM, Anthony Ferrara ircmax...@gmail.com wrote:
Hey all,
As promised, I've created
On Fri, Mar 9, 2012 at 10:58 AM, Ilia Alshanetsky i...@prohost.org wrote:
Anthony,
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.
But at least it's consistent with
Anthony Ferrara wrote:
So, what do you think?
I am a big fan of this style. Accepting e.g. 1abc as int(1) with a
notice seems like a better solution than anything else. A full error
would be too much towards strict typing (I wouldn't mind personally, but
others do have a strong opinion on
On Fri, Mar 9, 2012 at 3:58 AM, Ilia Alshanetsky i...@prohost.org wrote:
Anthony,
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.
This patch specifically tries to
44 matches
Mail list logo
