On Jan 2, 2015 12:24 PM, "Sara Golemon" wrote:
>
> I realize that ZE3 is not ZE2, but I always saw the ZEND_ENGINE_2
> define as more of a "At least ZE2" so that code of the form:
>
> #ifdef ZEND_ENGINE_2
> newAPI();
> #else /* ZE1 */
> oldAPI();
> #endif
>
> Would continue making sense (modul
I realize that ZE3 is not ZE2, but I always saw the ZEND_ENGINE_2
define as more of a "At least ZE2" so that code of the form:
#ifdef ZEND_ENGINE_2
newAPI();
#else /* ZE1 */
oldAPI();
#endif
Would continue making sense (modulo newNewAPI() in ZE3, of course).
Was the ZEND_ENGINE_2 define remo
I don't necessarily have any more insight to provide than has already
been done, but I do want to chime in and say that I personally favor
strict types as Nikita Popov has been advocating.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi!
> I'm referring to consistency with existing non-scalar type declarations
> supported by userland functions. They are strict.
There's no choice here as object types are not convertable in principle
(well, not unless we do convert ctors like C++ but IMHO that would be a
bit crazy). You can't e
Stanislav Malyshev wrote on 02.01.2015 01:57:
> Hi!
>
>> ZF2 completely broke compatibility with ZF1 users, so I think this is
>> a bad example.
>
> We're talking about different things here. PHP is an universal platform
> and PHP 7 would be offered as upgrade to all PHP users - running ZF1,
> Z
Hi!
> ZF2 completely broke compatibility with ZF1 users, so I think this is
> a bad example.
We're talking about different things here. PHP is an universal platform
and PHP 7 would be offered as upgrade to all PHP users - running ZF1,
ZF2, Symphony, Drupal, anything. If there would be a sizeable
On Fri, Jan 2, 2015 at 12:58 AM, Stanislav Malyshev
wrote:
> Hi!
>
> > Apart from being consistent with the existing behavior of type
> declarations
>
> We have no existing behavior of scalar type declarations except for
> hidden ones in internal functions and object types behave in PHP
> complet
On 01/01/2015 10:35 AM, Andrea Faulds wrote:
Now, going on step back here (talking about me), I'm speaking up because
my< needs are developer are different (mostly speaking about backend
code, interfaces, libraries, frameworks) but OTOH I'm not a big known
open source framework developer either
Hi!
> If they were case-sensitive, this would be inconsistent with other type names
> like array and callable.
Of course, I mean making all these hints case-sensitive. I have never
seen code using uppercase Callable or Array, though I imagine it might
happen. Github's search is case-insensitive
ZF2 completely broke compatibility with ZF1 users, so I think this is a bad
example.
Regards
Thomas
Stanislav Malyshev wrote on 02.01.2015 01:15:
> Hi!
>
>> Yeah, it’s a problem. I think some breakage here is inevitable,
>> unfortunately. Some of the classes with these names are stand-ins for
Hi Stas,
> On 2 Jan 2015, at 00:15, Stanislav Malyshev wrote:
>
> Hi!
>
>> Yeah, it’s a problem. I think some breakage here is inevitable,
>> unfortunately. Some of the classes with these names are stand-ins for
>> scalar type hints, so that code can “just” migrate to using actual
>> hints. But
> On 1 Jan 2015, at 23:58, Stanislav Malyshev wrote:
>
>> ability to check correct usage with tooling. I'd also like to point out
>> that Hack uses a strict type scheme and it seems to work well there (though
>
> Java uses strict typing too. And Perl has no typing whatsoever. So what?
> How bri
Hi!
> Yeah, it’s a problem. I think some breakage here is inevitable,
> unfortunately. Some of the classes with these names are stand-ins for
> scalar type hints, so that code can “just” migrate to using actual
> hints. But this doesn’t apply to all of them.
Breaking ZF2 and all software built on
Hi!
> The problem is that the current proposed hints/casts are deviating from the
> type-hints that we are used to, therefore this particular feature should
Let's check the manual we're used to.
http://php.net/manual/en/function.substr.php
string substr ( string $string , int $start [, int $leng
Hi!
> Apart from being consistent with the existing behavior of type declarations
We have no existing behavior of scalar type declarations except for
hidden ones in internal functions and object types behave in PHP
completely differently from scalars, so there's no place for
"consistency" claim h
Hi!
> Please use the term "type declaration for arguments" (or "type
> declaration for parameters") instead of "type hints". If it's used
> then it's not a hint.
Thank you! I was just going to post this. We've made this mistake once,
but we don't have to perpetuate it. It's no "hinting", it's
Hi,
On Thu, January 1, 2015 13:30, Dmitry Stogov wrote:
> Thanks for analizing.
> did you say "8.5 more" instructions? in my test I saw "less".
>
> It's really an intermedie step, and we probably will check if other
> optimizations are reaaly benefitable before committing this. But yes, this
> pa
> for the record this was proposed (as an idea) previously with the exact
same syntax(the earlies mention I could find in my mailbox was > from
Derick from 2009: http://comments.gmane.org/gmane.comp.php.devel/57653 but
I remember seeing it every time when this
> discussion happens).
> If somebody i
On 1 January 2015 at 14:05, Nikita Popov wrote:
>
> While in favor of introducing scalar type annotations, I'm against this
> proposal in particular. I've held a different position in the past, but by
> now I'm thoroughly convinced that if we introduce scalar type declarations,
> they should be st
when looking into phpdoc, e.g. http://de.php.net/substr we have string and int
everywhere in function definitions, do you want to change the whole
documentation?
Regards
Thomas
Levi Morrison wrote on 01.01.2015 18:19:
> On Thu, Jan 1, 2015 at 9:44 AM, Thomas Bley wrote:
>> I think it is no pr
Hey Levi,
> On 1 Jan 2015, at 17:19, Levi Morrison wrote:
>
> On Thu, Jan 1, 2015 at 9:44 AM, Thomas Bley wrote:
>> I think it is no problem to add strict parameter type hints with another rfc
>> (if this rfc gets accepted), e.g. function foobar(string! $str, int! $str){}
>> or any other synt
On Thu, Jan 1, 2015 at 9:44 AM, Thomas Bley wrote:
> I think it is no problem to add strict parameter type hints with another rfc
> (if this rfc gets accepted), e.g. function foobar(string! $str, int! $str){}
> or any other syntax.
>
I would rather have it the other way around. `string $str` is
> The problem is that the current proposed hints/casts are deviating from the
> type-hints that we are used to
I don't think type hints we currently have are different. The only difference
we have is that there is no automatic casting for objects/arrays to scalars and
scalars to objects/arrays (
Hey Marco,
> On 1 Jan 2015, at 16:56, Marco Pivetta wrote:
>
> The problem is that the current proposed hints/casts are deviating from the
> type-hints that we are used to, therefore this particular feature should
> (eventually) have an alternate syntax, whereas the strict hints would just
>
On 1 January 2015 at 17:44, Thomas Bley wrote:
> I think it is no problem to add strict parameter type hints with another
> rfc (if this rfc gets accepted), e.g. function foobar(string! $str, int!
> $str){} or any other syntax.
>
The problem is that the current proposed hints/casts are deviating
Hi Thomas,
> On 1 Jan 2015, at 16:54, Thomas Bley wrote:
>
> thanks for the rfc! Currently we allow:
>
> function test(Array $o){}
> test([]);
> function test2(array $o){}
> test2([]);
>
> So I propose to allow also uppercase type names:
> ublic function __construct(String $name, Int $age, Flo
Hi Nikita,
On Jan 1, 2015 5:23 PM, "Nikita Popov" wrote:
>
> On Wed, Dec 31, 2014 at 11:19 AM, Dmitry Stogov wrote:
>>
>> Hi,
>>
>> Please take a look into the patch
>>
>> https://github.com/php/php-src/pull/970/files
>>
>> This real changes are in zend_types.h, the rest is renaming that in most
thanks for the rfc! Currently we allow:
function test(Array $o){}
test([]);
function test2(array $o){}
test2([]);
So I propose to allow also uppercase type names:
ublic function __construct(String $name, Int $age, Float $cuteness, Bool $evil)
{
Regards
Thomas
Andrea Faulds wrote on 31.12.2014
I think it is no problem to add strict parameter type hints with another rfc
(if this rfc gets accepted), e.g. function foobar(string! $str, int! $str){} or
any other syntax.
Regards
Thomas
Nikita Popov wrote on 01.01.2015 15:05:
> On Wed, Dec 31, 2014 at 9:27 PM, Andrea Faulds wrote:
>
>> G
On Thu, Jan 1, 2015 at 4:59 PM, Marcio Almada wrote:
> The battle between strict type declarations vs coercive has been here for a
> while. My problem with coercion in detriment of strictness is
> that sometimes you DON'T WANT TYPE CASTING AT ALL. This new feature would
> create serious impedimen
Hi Markus,
> On 1 Jan 2015, at 15:58, Markus Fischer wrote:
>
> On 01.01.15 16:19, Andrea Faulds wrote:
>> I think it’d be weird to have different syntaxes for scalars and
>> non-scalars. We already use the syntax the RFC proposes in the PHP manual,
>> and I don’t think anyone’s confused by it
Woow. The compromise proposed by Marcio looks awesome to me :) .
Andrea, I can understand that in the PHP logic, but IMO if the RFC does not
avoid people that use code like I present before i don't think it's
completely relevant.
I mean, if people still use old tricks because the type hinting does
genius and simple syntax!
int $a === assertInt($a)
(int)$a === (int)$a
2015-01-01 18:59 GMT+03:00 Marcio Almada :
> The battle between strict type declarations vs coercive has been here for a
> while. My problem with coercion in detriment of strictness is
> that sometimes you DON'T WANT TYPE CAST
The battle between strict type declarations vs coercive has been here for a
while. My problem with coercion in detriment of strictness is
that sometimes you DON'T WANT TYPE CASTING AT ALL. This new feature would
create serious impediments. So I wonder if we couldn't have both (strict
and coercive t
Hello Andrea,
On 01.01.15 16:19, Andrea Faulds wrote:
> I think it’d be weird to have different syntaxes for scalars and non-scalars.
> We already use the syntax the RFC proposes in the PHP manual, and I don’t
> think anyone’s confused by it.
I didn't meant to stay there's something wrong with
Hey Nikita,
> On 1 Jan 2015, at 14:05, Nikita Popov wrote:
>
> While in favor of introducing scalar type annotations, I'm against this
> proposal in particular. I've held a different position in the past, but by
> now I'm thoroughly convinced that if we introduce scalar type declarations,
> t
Hi Maxime,
> On 1 Jan 2015, at 13:29, Maxime Veber wrote:
>
> I was expected an RFC like this in PHP for a while. I'm happy somebody made
> one, thanks.
Glad to hear that.
> But something hit me in that. even if you can't give an objet, you can give
> any scalar type that will be cast.
> I'm
Hey Zeev,
> On 1 Jan 2015, at 12:41, Zeev Suraski wrote:
>
> I like this draft too, and that's a first after countless proposals over the
> last decade - so kudos! :)
Glad to hear that.
> My main feedback here are the discrepancies between this RFC's casting rules
> and PHP's current built-in
Hi Markus,
> On 1 Jan 2015, at 11:09, Markus Fischer wrote:
>
> 1. the naming of the RFC thus the intent is confusing
>
> What it really does is it tries its best to convert, e.g. the RFC reads
> as it tries to work like this:
>
> function foo(int $bar) {
> $bar = (int)$bar;
> }
>
> From you
Hey Sebastian,
> On 1 Jan 2015, at 08:28, Sebastian Bergmann wrote:
>
> Am 31.12.2014 um 21:27 schrieb Andrea Faulds:
>> Parameter type hints for PHP’s scalar types
>
> Please use the term "type declaration for arguments" (or "type
> declaration for parameters") instead of "type hints". If it's
On Wed, Dec 31, 2014 at 9:27 PM, Andrea Faulds wrote:
> Good evening,
>
> Parameter type hints for PHP’s scalar types are a long-requested feature
> for PHP. Today I am proposing an RFC which is a new attempt to add them to
> the language. It is my hope that we can finally get this done for PHP 7
Hello,
I was expected an RFC like this in PHP for a while. I'm happy somebody made
one, thanks.
But something hit me in that. even if you can't give an objet, you can give
any scalar type that will be cast.
I'm not sure this behavior is very relevant.
Actually if I ask for a string, why the user
On Wed, Dec 31, 2014 at 11:19 AM, Dmitry Stogov wrote:
> Hi,
>
> Please take a look into the patch
>
> https://github.com/php/php-src/pull/970/files
>
> This real changes are in zend_types.h, the rest is renaming that in most
> cases makes code cleaner.
>
> zend_array didn't change its binary rep
Hi François,
this is not a proposal yet, this is just an initial request to the most
experinced PHP developers to think about possible consequnces.
Thanks. Dmitry.
On Dec 31, 2014 9:50 PM, "François Laupretre" wrote:
> > De : Dmitry Stogov [mailto:dmi...@zend.com]
>
> > Please take a look into
> -Original Message-
> From: Andrea Faulds [mailto:a...@ajf.me]
> Sent: Wednesday, December 31, 2014 10:28 PM
> To: PHP Internals
> Subject: [PHP-DEV] [RFC] Scalar Type Hints
>
> Good evening,
>
> Parameter type hints for PHP’s scalar types are a long-requested feature
> for
> PHP. Today I
Thanks for analizing.
did you say "8.5 more" instructions?
in my test I saw "less".
It's really an intermedie step, and we probably will check if other
optimizations are reaaly benefitable before committing this. But yes, this
patch doesn't make any degradation, except for slight increase of memor
Hello Sebastian,
On 01.01.15 09:28, Sebastian Bergmann wrote:
> Am 31.12.2014 um 21:27 schrieb Andrea Faulds:
>> Parameter type hints for PHP’s scalar types
>
> Please use the term "type declaration for arguments" (or "type
> declaration for parameters") instead of "type hints". If it's used
>
Am 31.12.2014 um 21:27 schrieb Andrea Faulds:
> Parameter type hints for PHP’s scalar types
Please use the term "type declaration for arguments" (or "type
declaration for parameters") instead of "type hints". If it's used
then it's not a hint.
--
PHP Internals - PHP Runtime Development Maili
48 matches
Mail list logo
