On 9 Mar, 2012, at 11:20 PM, Lazare Inepologlou 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 this be an
> 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 a
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 rea
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) { ..
> 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
From: Simon Schick [mailto:simonsimc...@googlemail.com]
>
> 2012/3/9 Lazare Inepologlou
> >
> > 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 b
2012/3/9 Lazare Inepologlou
>
> 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 know! So,
> 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(
> 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
Lazare,
On Fri, Mar 9, 2012 at 8:54 AM, Lazare Inepologlou 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 to see here:
>
>
2012/3/9 Lazare Inepologlou
>
> 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.
>
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
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 th
> > (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 a
> (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, w
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 propose
On Sun, Mar 4, 2012 at 00:28, Kris Craig 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 to be more explici
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
> Hey all,
>
> As promised, I've created a POC patch to implement scalar type hints,
> the way that zend_parse_parameter
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 un
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
On Fri, 09 Mar 2012 03:58:52 +0100, Ilia Alshanetsky
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 internal functions nowa
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.
Hi, all
At first, many thanks to Anthony for writing the code!
2012/3/9 Anthony Ferrara
> 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 allow this as well
On Fri, Mar 9, 2012 at 3:32 AM, Anthony Ferrara 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 :)
> So, what do
24 matches
Mail list logo
