On Mon, Jul 14, 2014 at 10:17 PM, Stas Malyshev
wrote:
> Hi!
>
> > Both of those are likely not to be installed on most systems. Why do
>
> Why not? bcmath is in core since forever and has no external
> requirements, gmp builds practically everywhere too. AFAIR all distros
> have it.
> --
> Stani
Hi!
> Both of those are likely not to be installed on most systems. Why do
Why not? bcmath is in core since forever and has no external
requirements, gmp builds practically everywhere too. AFAIR all distros
have it.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
--
VCS Account Rejected: jslingerland rejected by bjori /o\
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Andrea,
I need some education. Can you elaborate on the specific situations where
integer division would be used without other functions from bcmath or gmp?
I see in the RFC you mention seconds to hh:mm and index to rows/cols, but
can you give some actual "before" and "after" samples? Like t
Hi Andrea,
On Tue, Jul 15, 2014 at 9:14 AM, Andrea Faulds wrote:
> PHP currently lacks a way to do integer division. You can floor or int
> cast a floating-point division, but beyond 53-bits that produces the wrong
> result:
>
> $ sapi/cli/php -r 'var_dump((int)(PHP_INT_MAX / 3));'
> int(3074457
On 15 Jul 2014, at 01:58, Stas Malyshev wrote:
> INT_MAX is kind of an edge case,
It’s just an obvious example, integers beyond 2^53 fulfill this.
> if you need arbitrary-length precision
> you can always use gmp or bcmath.
I’m not asking for arbitrary-length precision, I’m asking for an inte
Hi!
> It elaborates a little more, so I’d suggest reading it first. What
> are your thoughts? I think this is a simple and obvious addition.
INT_MAX is kind of an edge case, if you need arbitrary-length precision
you can always use gmp or bcmath. I'm not sure this one-off use case
that is already
Good evening again,
PHP currently lacks a way to do integer division. You can floor or int cast a
floating-point division, but beyond 53-bits that produces the wrong result:
$ sapi/cli/php -r 'var_dump((int)(PHP_INT_MAX / 3));'
int(3074457345618258432)
Furthermore, using a floating-point divisi
Hi!
> I would have expected 1 - since it appears, from the code, that $a should
> only contain integers.
Until the time you changed it. If you write:
function foo(SplFileInfo $a) {
$a = 3 / 2;
}
Would you somehow expect $a to magically conjure SplFileInfo object out
of 3/2?
--
Stan
Hi!
>> cast to them, sure, because PHP as a rule allows you to cast anything to
>> anything explicitly (bar resources), but I can't, for example, do a
> loose
>> comparison between an array and a string.
>
> Exactly, that's my point. While you can explicitly cast scalars to arrays
> and even obj
Hi!
> In general, I am not in favour of casting typehints, as it would be a
> different behaviour from the hard-check typehints that we already have
> for classes and arrays.
It already is. All internal functions behave this way.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.
Hi!
> I suggested on IRC that empty strings, TRUE, FALSE, NULL, and values
> that validate for the int type hint could be accepted. Is that a good
> idea? Though it feels a bit loose, I think it covers all the
> important common use cases.
Then you need to make all internal functions that accept
Hi!
> That is exactly what is being proposed though. People (including
> Anthony himself, along with other proposals) have previously
> suggested type hints which just casted. However, I don’t think this
> is terribly useful. You can already do that really easily (`$foo =
> (int)$foo;`), and it’s
Hi!
> One of the issues with the RFC as it stands is how to handle bool
> casting. While int, float and string only allow lossless casting
> (with the exception of objects, but we can’t really do anything about
> that), bool’s behaviour at the moment is quite different. I don’t
> think it makes se
2014-07-15 1:24 GMT+03:00 Alain Williams :
> On Tue, Jul 15, 2014 at 01:16:49AM +0300, Park Framework wrote:
> > Maybe we should make two different syntax?
> >
> > fun(int $num, array $list) - for strict type compliance
> > fun((int) $num, (array) $list) - converted to type
>
> +1
>
> Don't
On Tue, Jul 15, 2014 at 01:16:49AM +0300, Park Framework wrote:
> Maybe we should make two different syntax?
>
> fun(int $num, array $list) - for strict type compliance
> fun((int) $num, (array) $list) - converted to type
+1
Don't forget to note that we will still retain the current synta
Maybe we should make two different syntax?
fun(int $num, array $list) - for strict type compliance
fun((int) $num, (array) $list) - converted to type
It will be very obvious, and without magic.
2014-07-14 23:23 GMT+03:00 Chuck Reeves :
> I am new to the list and internals so my question
I am new to the list and internals so my question might be obvious to
others: Why even cast the variable? When I look at a function and see:
function myFunc(array $someData)
{
//some processing
}
I understand that myFunc requires an array passed in. If I try to call
myFunc like so:
myFunc(
On 14 Jul 2014, at 20:53, Rowan Collins wrote:
> The debate in this thread basically comes down to us each wanting our
> favourite from that list of features to have the privilege of dedicated
> syntax in function signatures.
That’s why this RFC is supposed to be a best-compromise solution be
Lester Caine wrote (on 14/07/2014):
On 14/07/14 16:41, Andrea Faulds wrote:
The irritating thing here is HAVING to add the error_handler which may
well have been installed already for other reasons ... possibly in some
third party library to compensate for other changes?
The intention is obvio
On 14 Jul 2014, at 13:58, Andrea Faulds wrote:
>
> One of the issues with the RFC as it stands is how to handle bool casting.
> While int, float and string only allow lossless casting (with the exception
> of objects, but we can’t really do anything about that), bool’s behaviour at
> the mome
Andrea Faulds wrote (on 14/07/2014):
Arguably it’s inconsistent for the scalar and non-scalar type hints to work
slightly differently, but the point is that we’d be doing what makes sense for
arrays (no meaningful casts, so we don’t casts) and what makes sense for the
scalar types (there are c
On 14/07/14 16:41, Andrea Faulds wrote:
>> The irritating thing here is HAVING to add the error_handler which may
>> > well have been installed already for other reasons ... possibly in some
>> > third party library to compensate for other changes?
> The intention is obviously that you wouldn’t ski
> -Original Message-
> From: Andrea Faulds [mailto:a...@ajf.me]
> Sent: Monday, July 14, 2014 8:59 PM
> To: Zeev Suraski
> Cc: Rowan Collins; internals@lists.php.net
> Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
>
>
> On 14 Jul 2014, at 18:52, Zeev Suraski wrot
On 14 Jul 2014, at 18:52, Zeev Suraski wrote:
> Type hints were first and foremost introduced for object oriented safety, as
> a part of the major OO model shift Andi and I pushed for in PHP 5.0. What
> you may be alluding to - type hints for arrays and objects - were added at
> later time and
On 14 Jul 2014, at 18:38, Rowan Collins wrote:
> Andrea Faulds wrote (on 14/07/2014):
>> On 14 Jul 2014, at 18:24, Rowan Collins wrote:
>>
>>> If the current type hints were only for objects, I would be OK with that,
>>> but I really don't get why an array cast is so different from an int cas
> -Original Message-
> From: Rowan Collins [mailto:rowan.coll...@gmail.com]
> Sent: Monday, July 14, 2014 8:24 PM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
>
> Zeev Suraski wrote (on 14/07/2014):
> > I'd say absolutely yes, if t
Andrea Faulds wrote (on 14/07/2014):
On 14 Jul 2014, at 18:24, Rowan Collins wrote:
If the current type hints were only for objects, I would be OK with that, but I
really don't get why an array cast is so different from an int cast.
I’m don’t think the result of casting to array is meaningfu
On 14 Jul 2014, at 18:24, Rowan Collins wrote:
> If the current type hints were only for objects, I would be OK with that, but
> I really don't get why an array cast is so different from an int cast.
I’m don’t think the result of casting to array is meaningful or lossless for
anything
--
And
Zeev,
>> And passing 'hello' to a function type hinted as int? Will people really
>> expect
>> that to become a 0, with a mild warning they may not even have enabled?
>
> I'd say absolutely yes, if they're PHP developers that's exactly what they'd
> expect. After all, if you use 'hello' today in
Zeev Suraski wrote (on 14/07/2014):
I'd say absolutely yes, if they're PHP developers that's exactly what they'd
expect. After all, if you use 'hello' today in any integer context in PHP,
explicit or implicit, that's exactly how it will behavior across the
language.
And yet if you use it as a
On Mon, Jul 14, 2014 at 1:14 PM, Alain Williams wrote:
> On Mon, Jul 14, 2014 at 06:09:22PM +0100, Andrea Faulds wrote:
> >
> > On 14 Jul 2014, at 18:01, Alain Williams wrote:
> >
> > > But if you have:
> > >
> > >function foo(int $a) {
> > >...
> > > $a = 3 / 2;
> > >}
> > >
On 14 Jul 2014, at 18:14, Alain Williams wrote:
> I trust that you meant 1.5 not 0.666.
Er… yes. I somehow misread 3/2 as 2/3.
> I would have expected 1 - since it appears, from the code, that $a should
> only contain integers.
So? PHP doesn’t do integer division. It does what Python 3 does:
On Mon, Jul 14, 2014 at 06:09:22PM +0100, Andrea Faulds wrote:
>
> On 14 Jul 2014, at 18:01, Alain Williams wrote:
>
> > But if you have:
> >
> >function foo(int $a) {
> >...
> > $a = 3 / 2;
> >}
> >
> > What do you expect $a to contain ? I would suggest integer 1.
>
> I’d
On 14 Jul 2014, at 18:11, Alain Williams wrote:
> Since we are looking at doing this what good reason is there for not adopting
> the syntax & some of the semantics of Hack ?
>
>http://docs.hhvm.com/manual/en/hack.annotations.php
>
> NIH is not a good reason.
>
> NIH = Not Invented Here
On Mon, Jul 14, 2014 at 05:14:04PM +0100, Rowan Collins wrote:
> The only *consistent* behaviour is strict validation, period. If you
> want that, use Hack; if you want some other kind of type hint, it
> has to introduce something new.
Since we are looking at doing this what good reason is there
On 14 Jul 2014, at 18:01, Alain Williams wrote:
> But if you have:
>
>function foo(int $a) {
>...
> $a = 3 / 2;
>}
>
> What do you expect $a to contain ? I would suggest integer 1.
I’d expect (and I think most people new to PHP would expect) what 3/2 would be
in normal
On Mon, Jul 14, 2014 at 11:01 AM, Alain Williams wrote:
> On Mon, Jul 14, 2014 at 12:25:22PM -0400, Anthony Ferrara wrote:
>
>> IMHO, strict hints are dangerous in the context of PHP because PHP's
>> types can change in unpredictable ways. A variable that was an integer
>> can turn into a float th
On Mon, Jul 14, 2014 at 12:25:22PM -0400, Anthony Ferrara wrote:
> IMHO, strict hints are dangerous in the context of PHP because PHP's
> types can change in unpredictable ways. A variable that was an integer
> can turn into a float through seemingly integer operations. Example:
> $a / $b * $b wil
> -Original Message-
> From: Rowan Collins [mailto:rowan.coll...@gmail.com]
> Sent: Monday, July 14, 2014 7:44 PM
> To: Zeev Suraski; Andrea Faulds
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
>
> Zeev Suraski wrote (on 14/07/2014)
> -Original Message-
> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
> Sent: Monday, July 14, 2014 7:25 PM
> To: Zeev Suraski
> Cc: Rowan Collins; internals@lists.php.net
> Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
>
> Zeev,
>
> > Actually there's a prett
Zeev Suraski wrote (on 14/07/2014):
I do believe that the vast majority of people would want '32 ' and "42\n"
to silently convert to 32/42, and will generally not care much about
'32abc' converting to 32 either for the sake of consistency.
And passing 'hello' to a function type hinted as int? W
On Mon, Jul 7, 2014 at 4:18 PM, Nikita Popov wrote:
> Hi internals!
>
> I've started the vote on the Uniform Variable Syntax RFC:
>
> https://wiki.php.net/rfc/uniform_variable_syntax#vote
>
> You can review the discussion about this RFC here:
>
> http://markmail.org/message/mr4ihbubfbdxyg
> -Original Message-
> From: Andrea Faulds [mailto:a...@ajf.me]
> Sent: Monday, July 14, 2014 7:12 PM
> To: Zeev Suraski
> Cc: Rowan Collins; internals@lists.php.net
> Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
>
> > 2. It encourages developers to get the types
Zeev,
> Actually there's a pretty simple way that's not strict type hints:
>
> 5) Add type hints using existing syntax, which are casts; Change casts
> (both existing and these new ones) to emit a new E_CAST in case of data
> loss or 'bogus' conversions.
The issue with this, is that it changes h
Zeev Suraski wrote (on 14/07/2014):
-Original Message-
From: Rowan Collins [mailto:rowan.coll...@gmail.com]
Sent: Monday, July 14, 2014 6:28 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
Derick Rethans wrote (on 14/07/2014):
A co
On 14 Jul 2014, at 17:04, Zeev Suraski wrote:
> 1. It saves a bit of code and improves readability for a *very* common use
> case.
Sure.
> 2. It encourages developers to get the types straight instead of relying
> on implicit casts.
Your proposal is to just use implicit casts with no real fai
> -Original Message-
> From: Andrea Faulds [mailto:a...@ajf.me]
> Sent: Monday, July 14, 2014 6:49 PM
> To: Zeev Suraski
> Cc: Rowan Collins; internals@lists.php.net
> Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
>
>
> On 14 Jul 2014, at 16:46, Zeev Suraski wrot
On 14 Jul 2014, at 16:46, Zeev Suraski wrote:
> Actually there's a pretty simple way that's not strict type hints:
>
> 5) Add type hints using existing syntax, which are casts; Change casts
> (both existing and these new ones) to emit a new E_CAST in case of data
> loss or 'bogus' conversions.
> -Original Message-
> From: Rowan Collins [mailto:rowan.coll...@gmail.com]
> Sent: Monday, July 14, 2014 6:28 PM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
>
> Derick Rethans wrote (on 14/07/2014):
> > A compromise by adding mor
On 14 Jul 2014, at 16:39, Lester Caine wrote:
> The irritating thing here is HAVING to add the error_handler which may
> well have been installed already for other reasons ... possibly in some
> third party library to compensate for other changes?
The intention is obviously that you wouldn’t sk
On 14/07/14 16:11, Andrea Faulds wrote:
>> It does, as it creates an error (recoverable or not), and it doesn't allow
>> > "13abc" to easily turn into 13 (int), even if you implement an error
>> > handler that ignores E_RECOVERABLE_ERROR.
> Actually, you’re right. In the current patch, if you run t
Derick Rethans wrote (on 14/07/2014):
A compromise by adding more inconsistencies.
The only way of not introducing some inconsistencies (or, to put it
another way, new features) is to use strict type hints, which perform no
casting, and error on invalid input, since that's what the existing t
> -Original Message-
> From: Andrea Faulds [mailto:a...@ajf.me]
> Sent: Monday, July 14, 2014 6:12 PM
> To: Zeev Suraski
> Cc: Derick Rethans; PHP internals
> Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
>
>
> On 14 Jul 2014, at 16:07, Zeev Suraski wrote:
>
> >
On 14 Jul 2014, at 15:17, Andrea Faulds wrote:
>
> On 14 Jul 2014, at 15:03, Rowan Collins wrote:
>
>> Looking at the current table in the RFC, I'm not clear why NULL should pass
>> as any value, but not array. Could it not behave the same as the existing
>> type hints, i.e. accepted only i
On 14 Jul 2014, at 16:07, Zeev Suraski wrote:
> It does, as it creates an error (recoverable or not), and it doesn't allow
> "13abc" to easily turn into 13 (int), even if you implement an error
> handler that ignores E_RECOVERABLE_ERROR.
Actually, you’re right. In the current patch, if you run
> -Original Message-
> From: Andrea Faulds [mailto:a...@ajf.me]
> Sent: Monday, July 14, 2014 5:58 PM
> To: Derick Rethans
> Cc: PHP internals
> Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
>
>
> On 14 Jul 2014, at 15:54, Derick Rethans wrote:
>
> > A compromise
> A compromise by adding more inconsistencies.
I agree.
> I can buy the cast of scalars vs hint--of-complex types, but definitely
> not the
> introduction of a new group of casting rules. Keep it simple.
I agree too.
And it should not be a recoverable error, it should be a notice (or
equivalent
On 14 Jul 2014, at 18:57, Andrea Faulds wrote:
> On 14 Jul 2014, at 15:54, Derick Rethans wrote:
>
>> A compromise by adding more inconsistencies.
>>
>> I can buy the cast of scalars vs hint--of-complex types, but definitely
>> not the introduction of a new group of casting rules. Keep it simp
On 14 Jul 2014, at 15:54, Derick Rethans wrote:
> A compromise by adding more inconsistencies.
>
> I can buy the cast of scalars vs hint--of-complex types, but definitely
> not the introduction of a new group of casting rules. Keep it simple.
It doesn’t change the casting rules; write an erro
On Mon, 14 Jul 2014, Andrea Faulds wrote:
>
> On 14 Jul 2014, at 15:38, Derick Rethans wrote:
>
> > I am worried about this big casting conversion matrix. New rules should
> > not be invented, and the following should *always* be equivalent:
> >
> > function foo(typehint $var)
> >
> > vs
On 14 Jul 2014, at 15:38, Derick Rethans wrote:
> I am worried about this big casting conversion matrix. New rules should
> not be invented, and the following should *always* be equivalent:
>
> function foo(typehint $var)
>
> vs:
>
> function foo($var) {
> $var = ty
On Sun, 13 Jul 2014, Andrea Faulds wrote:
> The RFC is here:
> https://wiki.php.net/rfc/scalar_type_hinting_with_cast
I am worried about this big casting conversion matrix. New rules should
not be invented, and the following should *always* be equivalent:
function foo(typehint $var)
v
On 14 Jul 2014, at 15:03, Rowan Collins wrote:
> Looking at the current table in the RFC, I'm not clear why NULL should pass
> as any value, but not array. Could it not behave the same as the existing
> type hints, i.e. accepted only if declared as a default?
>
> function foo(array $bar) { }
Arvids Godjuks wrote (on 14/07/2014):
There is no special casing, Array and Object type hints are already
implemented and are in the language for quite a long time. Just don't
touch them, that's all I ask.
The special case existing for backwards compatibility doesn't make it
less of a special
Andrea Faulds wrote (on 14/07/2014):
One of the issues with the RFC as it stands is how to handle bool casting.
While int, float and string only allow lossless casting (with the exception of
objects, but we can’t really do anything about that), bool’s behaviour at the
moment is quite different
On Mon, Jul 14, 2014 at 4:27 PM, Rowan Collins wrote:
> Andrey Andreev wrote (on 14/07/2014):
>
>> Hi,
>>
>> On Mon, Jul 14, 2014 at 4:12 PM, Alexey Zakhlestin
>> wrote:
>>>
>>> Some people talk about inconsistency, which is introduced by reusing same
>>> syntax for "strict parameter types" and "
On Mon, Jul 14, 2014 at 01:58:25PM +0100, Andrea Faulds wrote:
> Hello again,
>
> One of the issues with the RFC as it stands is how to handle bool casting.
> While int, float and string only allow lossless casting (with the exception
> of objects, but we can’t really do anything about that), bo
2014-07-14 15:41 GMT+03:00 Rowan Collins :
> Arvids Godjuks wrote (on 14/07/2014):
>
> We already have quite good implementation for the array and object hints,
>> they do their job and do it good. No need to change those at all - leave
>> them as is - no need to add magic with casts and all that
On 14 Jul 2014, at 14:33, Chris Wright wrote:
> 2) A common-ish use case here would be:
>
> function foo(bool $bool) {}
> foo($flags & A_FLAG);
>
> The intent of the expression $flags & A_FLAG is obvious to the reader
> as fetching a boolean, but the result will often be an integer that is
On 14 July 2014 13:58, Andrea Faulds wrote:
> Hello again,
>
> One of the issues with the RFC as it stands is how to handle bool casting.
> While int, float and string only allow lossless casting (with the exception
> of objects, but we can’t really do anything about that), bool’s behaviour at
2014-07-14 14:19 GMT+03:00 Alain Williams :
> On Mon, Jul 14, 2014 at 01:09:42PM +0300, Arvids Godjuks wrote:
>
> > PHP does not need a type hinting system forces you to first make a
>
> No one is 'forcing' anything. You use it where it is appropriate; that
> does not
> mean everywhere - there are
On 14/07/14 13:58, Andrea Faulds wrote:
> The final option I’m thinking about is a limited set of values. TRUE, FALSE
> and NULL would be accepted, along with the integer and float values 1 and 0
> (which are the int/float TRUE and FALSE cast to, respectively), ‘1’ and the
> empty string (which
On 14 Jul 2014, at 14:29, Jocelyn Fournier wrote:
> Actually both syntax could exists :
>
> function foo((int) $a)
> {
>
> => scalar parameter casts syntax
>
>
> function foo(int $a)
> {
>
> => strict type checking syntax (consistant with array / class syntax)
I believe supporting both syn
Andrey Andreev wrote (on 14/07/2014):
Hi,
On Mon, Jul 14, 2014 at 4:12 PM, Alexey Zakhlestin wrote:
Some people talk about inconsistency, which is introduced by reusing same syntax for
"strict parameter types" and "scalar parameter casts”. There’s some truth there.
Let’s use different syntax.
Hi,
Le 14/07/2014 15:19, Andrey Andreev a écrit :
Hi,
On Mon, Jul 14, 2014 at 4:12 PM, Alexey Zakhlestin wrote:
Some people talk about inconsistency, which is introduced by reusing same syntax for
"strict parameter types" and "scalar parameter casts”. There’s some truth there.
Let’s use diff
On 14 Jul 2014, at 14:28, Andrea Faulds wrote:
>
> On 14 Jul 2014, at 14:12, Alexey Zakhlestin wrote:
>
>> I don’t think that "scalar casts” should do any additional error-catching.
>> they target a very different usecase.
>> It shouldn’t guarantee correctness of the whole program. It should
VCS Account Rejected: bdrsuh rejected by rasmus /o\
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 14 Jul 2014, at 14:12, Alexey Zakhlestin wrote:
> I don’t think that "scalar casts” should do any additional error-catching.
> they target a very different usecase.
> It shouldn’t guarantee correctness of the whole program. It should guarantee
> that variable types are fixed inside of funct
Hi,
On Mon, Jul 14, 2014 at 4:12 PM, Alexey Zakhlestin wrote:
> Some people talk about inconsistency, which is introduced by reusing same
> syntax for "strict parameter types" and "scalar parameter casts”. There’s
> some truth there.
> Let’s use different syntax.
>
> This might work:
>
> fu
On 14 Jul 2014, at 16:58, Andrea Faulds wrote:
> One of the issues with the RFC as it stands is how to handle bool casting.
> While int, float and string only allow lossless casting (with the exception
> of objects, but we can’t really do anything about that), bool’s behaviour at
> the moment
Hello again,
One of the issues with the RFC as it stands is how to handle bool casting.
While int, float and string only allow lossless casting (with the exception of
objects, but we can’t really do anything about that), bool’s behaviour at the
moment is quite different. I don’t think it makes
Alain Williams wrote (on 14/07/2014):
This sort of error should be picked up the first time that the script is
compiled, it does not need to be executed (other than conditional includes).
This means that these errors will be picked up very quickly.
So, it doesn't need to be executed ... except
On Mon, Jul 14, 2014 at 2:35 PM, Alain Williams wrote:
> On Mon, Jul 14, 2014 at 02:19:15PM +0200, Ferenc Kovacs wrote:
>
> > > function foo(int $a)
> > > {
> > > var $b;// $b has no type hinting
> > > var float $c; // $c is a float
> > > string $d; //
Arvids Godjuks wrote (on 14/07/2014):
We already have quite good implementation for the array and object hints,
they do their job and do it good. No need to change those at all - leave
them as is - no need to add magic with casts and all that. Function/method
requires an array? Make casts explici
On Mon, Jul 14, 2014 at 02:19:15PM +0200, Ferenc Kovacs wrote:
> > function foo(int $a)
> > {
> > var $b;// $b has no type hinting
> > var float $c; // $c is a float
> > string $d; // alternative to the syntax used for $c (see below)
> > }
> I thin
On Sun, Jul 13, 2014 at 12:18 PM, Alain Williams wrote:
> On Sun, Jul 13, 2014 at 09:16:33AM +0100, Lester Caine wrote:
> > On 13/07/14 06:22, Stas Malyshev wrote:
> > > It is very direct specification of
> > > either strict parameter typing or coercive parameter typing. I don't
> > > think using
On Mon, Jul 14, 2014 at 01:09:42PM +0300, Arvids Godjuks wrote:
> PHP does not need a type hinting system forces you to first make a
No one is 'forcing' anything. You use it where it is appropriate; that does not
mean everywhere - there are plenty of places where I would not want to use it.
> P.
Hello!
As a user land developer I do think that over thinking this is going to end
up in disaster.
We already have quite good implementation for the array and object hints,
they do their job and do it good. No need to change those at all - leave
them as is - no need to add magic with casts and all
89 matches
Mail list logo
