[PHP-DEV] IDN support in streams

Hello, I've submitted a PR to add IDN support in PHP streams. The way it's done will allow easy IDN domain validation in ext/filter too. Can you review this PR please? https://github.com/php/php-src/pull/890 -- Kévin Dunglas Consultant et développeur freelance http://dunglas.fr Tél. : 06 60 9

Re: [PHP-DEV] Types on the right or on the left

On Nov 4, 2014 5:28 AM, "Stas Malyshev" wrote: > > Hi! > > > PHP doesn’t need more inconsistency, sure, but we must be practical > > here. It is bad if PHP and Hack have the same feature with different > > syntax, it will cause developer confusion and further segment the > > communities. > > Given

[PHP-DEV] Re: opcache.revalidate_freq is PHP_INI_ALL?

On 11/04/2014 06:33 PM, Dmitry Stogov wrote: > Hi Rasmus, > > Sorry for delay, I'm just back to work after ZendCon and holidays. > > opcache.revalidate_freq is PHP_INI_ALL on purpose. > Scripts that generate and include the same file again and again should > set it to 0 to check for modification

Re: [PHP-DEV] Types on the right or on the left

Hi! > C++11 adds suffixed types for returns despite having prefixed types > for everything else, including previous return types. C++ does it for entirely different reasons, related to scoping, and it still has "auto" type at the beginning. In any case, I'd be very vary taking late C++ hacks as a

Re: [PHP-DEV] Types on the right or on the left

I reformatted Stas' arguments to a form better for point-by-point discussion; I'm sorry if I lost too much information when doing so. 1) It's more "natural" to do a prefixed type. This is the same thing that I am claiming, just from the opposite viewpoint. 2) Type prefixed parameters and type su

Re: [PHP-DEV] Types on the right or on the left

Hi! > What arguments do you have in favor of doing ` "function" > "( ")`? So far I haven't heard any We already using "type before entity" for parameter typing, and it is a natural way to do it, both from linguistic perspective (in English, we say "green house", not "house: green") and it is th

[PHP-DEV] Re: opcache.revalidate_freq is PHP_INI_ALL?

Hi Rasmus, Sorry for delay, I'm just back to work after ZendCon and holidays. opcache.revalidate_freq is PHP_INI_ALL on purpose. Scripts that generate and include the same file again and again should set it to 0 to check for modification on each include. I didn't get what did you meant by "but i

[PHP-DEV] Lazy writing in the session, session-lock-ini, and bug #68331

https://bugs.php.net/bug.php?id=68331 I was hoping the submitter (or one of their coworkers who commented on it) would reach out to the list themselves to get more information since I don't know the whole situation. I did ask them to... Story thus far: Yasuo's session-lock-ini RFC [1] in February

Re: [PHP-DEV] Types on the right or on the left

I apologize: my baby managed to send my email premature. I'm not even sure what hotkey he hit ^^ >> Except `static function()` and `static function foo()` already have >> meaning, and if we allowed static return types (very possible) that >> would be ambiguous. This syntax is a no-go. > > If it is

Re: [PHP-DEV] Types on the right or on the left

>> Except `static function()` and `static function foo()` already have >> meaning, and if we allowed static return types (very possible) that >> would be ambiguous. This syntax is a no-go. > > If it is possible, why it's not the part of the RFC? Probably because > there's not much place where it wo

Re: [PHP-DEV] Types on the right or on the left

On Tue, Nov 4, 2014 at 6:05 PM, Stas Malyshev wrote: > Hi! > >> Except `static function()` and `static function foo()` already have >> meaning, and if we allowed static return types (very possible) that >> would be ambiguous. This syntax is a no-go. > > If it is possible, why it's not the part of

Re: [PHP-DEV] Types on the right or on the left

On Tue, Nov 4, 2014 at 5:55 PM, Rasmus Lerdorf wrote: > On 11/04/2014 04:42 PM, Levi Morrison wrote: If we used this syntax instead, which wouldn’t disrupt grep: public Foo function bar(); It’d be inconsistent with normal function declarations which would have to

Re: [PHP-DEV] Types on the right or on the left

Hi! > Except `static function()` and `static function foo()` already have > meaning, and if we allowed static return types (very possible) that > would be ambiguous. This syntax is a no-go. If it is possible, why it's not the part of the RFC? Probably because there's not much place where it would

Re: [PHP-DEV] Types on the right or on the left

On 11/04/2014 04:42 PM, Levi Morrison wrote: >>> If we used this syntax instead, which wouldn’t disrupt grep: >>> >>> public Foo function bar(); >>> >>> It’d be inconsistent with normal function declarations which would have to >>> have Foo after function. >> >> I don't understand that inconsi

Re: [PHP-DEV] Types on the right or on the left

>> If we used this syntax instead, which wouldn’t disrupt grep: >> >> public Foo function bar(); >> >> It’d be inconsistent with normal function declarations which would have to >> have Foo after function. > > I don't understand that inconsistency. > >public Foo function bar() { } > > look

[PHP-DEV] RFC Process: Should we hold two different votes?

Good evening, A lot of RFCs have been rejected because, while they proposed a feature people would like, the details were problematic. This has lead to these features sometimes being considerably delayed. So, in order to do something about this, here’s an idea: Why not hold two different votes

Re: [PHP-DEV] Annotation PHP 7

Sorry, I forgot to add references to how we fixed emails handling. It got split in 2 places: - Initial root level annotation https://github.com/doctrine/annotations/blob/master/lib/Doctrine/Common/Annotations/DocParser.php#L350 - Subsequent root level annotations https://github.com/doctrine/annot

Re: [PHP-DEV] Annotation PHP 7

Hi, By dealing with annotations in docblocks will force the Annotations parser to *much* smarter than you imagine. Currently in Doctrine Annotations implementation, @param and @Param are considered different not only by first character to be uppercased, but rather because a class also exist in th

Re: [PHP-DEV] Annotation PHP 7

> On 4 Nov 2014, at 21:31, Stas Malyshev wrote: > >> This brings the next piece of the puzzle. We have to update lexical and >> semantical understanding of PHP. Taking Java's approach (@) does not >> work in PHP, because it conflicts with error supression. Same thing > > Except for the mental c

Re: [PHP-DEV] Annotation PHP 7

On 04/11/14 21:24, Sebastian B.-Hagensen wrote: > Just as a note: /** and /* are already treated differently by the > parser (T_DOC_COMMENT vs. T_COMMENT, this difference is also present > in opcache). > > Anyway, metadata/annotations/whatever you want to call them should be > seperated from comme

Re: [PHP-DEV] Annotation PHP 7

Hi! > Primarily, I do not see docblocks as the right place to store class' metadata information. Metadata != Comments. I personally regard this as a kind of superstition. There's nothing wrong with extending what can be in comments. In fact, Javascript was officially "HTML comment" for years, an

Re: [PHP-DEV] Annotation PHP 7

Just as a note: /** and /* are already treated differently by the parser (T_DOC_COMMENT vs. T_COMMENT, this difference is also present in opcache). Anyway, metadata/annotations/whatever you want to call them should be seperated from comments and verbal descriptions on a syntax level, not just by s

Re: AW: [PHP-DEV] Types on the right or on the left

2014-11-04 9:51 GMT-08:00 Stas Malyshev : > Hi! > > > I thought it was inconsistent, but after discussions on > > StackOverflow, I don't think it actually is. > > If you specify the type once as "Foo something" and once as "something: > Foo" then I don't see how there's even a place for discussion

Re: [PHP-DEV] Annotation PHP 7

On 04/11/14 20:18, guilhermebla...@gmail.com wrote: > Primarily, I do not see docblocks as the right place to store class' > metadata information. Metadata != Comments. We use comment wrappers in many places to hide secondary material from other processes. Just rename docblocks -> metadata ... wha

Re: [PHP-DEV] [RFC] Additional splat operator usage

> On 4 Nov 2014, at 18:14, Rowan Collins wrote: > > On 3 November 2014 22:45:11 GMT, Chris Wright wrote: >> Good evening list, >> >> I'd like to open discussion a relatively simple and clear-cut RFC, >> either >> people will like it or they won't, there isn't a lot more to say here >> than >>

Re: [PHP-DEV] Add a new flag for json_encode

> On 4 Nov 2014, at 20:06, Jakub Zelenka wrote: > > That's a good point. However I still think that there are more advantages for > making this the default. I like mainly the idea that > json_decode(json_encode($a)) = $a for all floats which is not the case at the > moment. Also it allow some

Re: [PHP-DEV] Annotation PHP 7

Hi, As one of the original authors of both Doctrine Annotations and previous RFC of native Annotations in PHP, I can go thoroughly on every specific detail about challenges of design decisions to make. Primarily, I do not see docblocks as the right place to store class' metadata information. Meta

Re: [PHP-DEV] [RFC] Additional splat operator usage

I like the idea, especially list($a, $b, ...$c) = ... Looks like Prolog's [A, B | C] = ..., unfortunately it won't provide the same semantic and performance. Implementation needs to be reviewed, but I think it must not affect existing opcodes. Thanks. Dmitry. On Tue, Nov 4, 2014 at 1:45 AM, Chris

Re: [PHP-DEV] Annotation PHP 7

>> In Python, decorators are very >> powerful for modifying function behavior (i.e., attaching pre/post >> conditions to functions or doing some things phpunit does is really >> easy) but it is too much for just attaching data. FWIW (and I apologize if this is just adding to the noise), one of the

Re: [PHP-DEV] Add a new flag for json_encode

Hi, On Tue, Nov 4, 2014 at 6:14 PM, Andrea Faulds wrote: > > > On 4 Nov 2014, at 17:07, Jakub Zelenka wrote: > > > > I would really like to see it as default in the next major as it is a > > useful feature. > > > > However I don't like adding new flag. The reason for that is that it > > becomes

Re: [PHP-DEV] [RFC] [VOTE] Filtered unserialize()

Hi! > To clarify: I don't think it makes sense to add an additional security > option, if we cannot say that unserialize() is to our knowledge *fully* That's where we disagree. I think security is a spectrum, and you can make it better. It looks like you think it's binary - either it is *fully* a

Re: [PHP-DEV] Annotation PHP 7

If this is difficult, you can do in PHP 7.0 simple realization annotation/facades, in versions 7.x to develop and refine. Most importantly, define the syntax and semantics annotation/facades, for a version of PHP 7.0 Demand in annotation/facades is very high, ~80% of all popular frameworks their

Re: [PHP-DEV] Types on the right or on the left

On Tue, Nov 4, 2014 at 11:48 AM, Stas Malyshev wrote: > Hi! > >> But it’s rather weird for closures: >> >> $foo = Foo function () { >> }; > > Not much weirder than: > > $foo = static function () { ... } > > which we already have. Putting modifiers in front of the function is > nothing fore

Re: [PHP-DEV] [RFC] [VOTE] Filtered unserialize()

I agree with Nikita. Adding an extra argument for one particular security related case looks weird. Will we add more arguments for others? I would also prefer options array and [] instead of 'false'. unserialize($string, array('allowed_classes'=>[])); It's also more readable :) Thanks. Dmitry.

Re: [PHP-DEV] [RFC] [VOTE] Filtered unserialize()

On Tue, Nov 4, 2014 at 7:45 PM, Stas Malyshev wrote: > Hi! > > > I'm -1 on this RFC, because I think this only further encourages > > ill-advised usages of unserialize() on user-provided strings. I don't > > I guess that's where we disagree. I think that security is a layered > approach (see more

Re: [PHP-DEV] Annotation PHP 7

> On 4 Nov 2014, at 18:27, Stas Malyshev wrote: > > For python-style decorators, at least the way they work in Python, we'd > need to organize our function tables differently, as Python just > replaces the function with another one while decorating, and I'm not > sure it'd be as easy to do with

Re: [PHP-DEV] Types on the right or on the left

Hi! > But it’s rather weird for closures: > > $foo = Foo function () { > }; Not much weirder than: $foo = static function () { ... } which we already have. Putting modifiers in front of the function is nothing foreign to PHP. -- Stanislav Malyshev, Software Architect SugarCRM: http:/

Re: [PHP-DEV] [RFC] [VOTE] Filtered unserialize()

Hi! > I'm -1 on this RFC, because I think this only further encourages > ill-advised usages of unserialize() on user-provided strings. I don't I guess that's where we disagree. I think that security is a layered approach (see more here: http://php100.wordpress.com/2014/11/03/unserialize-and-being

Re: [PHP-DEV] Types on the right or on the left

> On 4 Nov 2014, at 18:33, Stas Malyshev wrote: > >> If we used this syntax instead, which wouldn’t disrupt grep: >> >>public Foo function bar(); >> >> It’d be inconsistent with normal function declarations which would have to >> have Foo after function. > > What's "normal function" and

Re: [PHP-DEV] [RFC] [VOTE] Filtered unserialize()

On Mon, Nov 3, 2014 at 10:10 PM, Stas Malyshev wrote: > Hi! > > I'd like to put to vote my proposal about the filtered unserialize(): > > https://wiki.php.net/rfc/secure_unserialize > > It was discussed a number of times before and I think it is time to have > a decision on it. If you need any cl

Re: [PHP-DEV] Annotation PHP 7

On 04.11.2014 17:34, Andrea Faulds wrote: > In Python, a decorator is a function (or callable object), and you use one > like this: > > @some_decorator(foo, bar) > def myfunc(): > # function source code here I wonder how feasible it would be to add something like this and allow e

Re: [PHP-DEV] Types on the right or on the left

Hi! > Because if that function has a return type, e.g.: > > public function Foo bar() > > Then you couldn’t grep for “function bar” because of the Foo. And that's not what I have proposed. Would anybody actually *read* what I am proposing? Or reading is optional for discussion now? > If we

Re: [PHP-DEV] Annotation PHP 7

> Reading it - > http://doctrine-common.readthedocs.org/en/latest/reference/annotations.html - > it looks pretty big - strictly typed values, named > parameters, default constructors linked to properties, support for enum > types, support for typed arrays, separate constant syntax within > annotat

Re: [PHP-DEV] Annotation PHP 7

Hi! > The approach for annotations that I like best would actually be not > annotations, but Python-style decorators. They’re very simple, but > very powerful. They would allow you to do annotations, but also add > extra functionality to functions. For python-style decorators, at least the way th

Re: [PHP-DEV] Types on the right or on the left

Andrea Faulds wrote: > For parameters, the type is of the thing itself: > > function foo(Foo $foo, Bar $bar); > > Here, $foo is of the type Foo, and $bar is of the type Bar. > > But say if we were to add return types like this: > > function FooBar qux(); > > The type of qux isn’t a Fo

Re: [PHP-DEV] Annotation PHP 7

Hi! > All projects mentioned in this thread use: > http://doctrine-common.readthedocs.org/en/latest/reference/annotations.html > That makes a pretty good base spec. Reading it, it looks pretty big - strictly typed values, named parameters, default constructors linked to properties, support for en

Re: [PHP-DEV] Types on the right or on the left

On 11/04/2014 10:08 AM, Andrea Faulds wrote: > >> On 4 Nov 2014, at 17:46, Stas Malyshev wrote: >> >> Hi! >> "public Foo function bar()" would be so much worse than "public function bar() : Foo" >>> >>> Because when you grep for "function bar", in future you'd have to know >>> the retur

Re: [PHP-DEV] [RFC] Additional splat operator usage

On 3 November 2014 22:45:11 GMT, Chris Wright wrote: >Good evening list, > >I'd like to open discussion a relatively simple and clear-cut RFC, >either >people will like it or they won't, there isn't a lot more to say here >than >what's in the RFC so please have a read. > >https://wiki.php.net/rfc/

Re: [PHP-DEV] Add a new flag for json_encode

> On 4 Nov 2014, at 17:07, Jakub Zelenka wrote: > > I would really like to see it as default in the next major as it is a > useful feature. > > However I don't like adding new flag. The reason for that is that it > becomes useless after 7 is realesed. It would be useful only for >5.6.3 and > <7

Re: [PHP-DEV] Add a new flag for json_encode

> On 4 Nov 2014, at 16:41, Ferenc Kovacs wrote: > > > > On Tue, Nov 4, 2014 at 5:35 PM, Andrea Faulds wrote: > > > On 4 Nov 2014, at 14:57, Ferenc Kovacs wrote: > > > > Hi, > > > > just a slight correction: > > as far as I can tell, Jakus was ok with the general idea and even with > > turni

Re: [PHP-DEV] Types on the right or on the left

> On 4 Nov 2014, at 17:46, Stas Malyshev wrote: > > Hi! > >>> "public Foo function bar()" would be so much worse than "public function >>> bar() : Foo" >> >> Because when you grep for "function bar", in future you'd have to know >> the return type too. > > Sorry, I do not understand - why to

Re: AW: [PHP-DEV] Types on the right or on the left

Hi! > In PHP, input types go on the left and output types go on the right. What is the "output type"? If I wanted to type a variable - is it input or output? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To

Re: AW: [PHP-DEV] Types on the right or on the left

Hi! > I thought it was inconsistent, but after discussions on > StackOverflow, I don't think it actually is. If you specify the type once as "Foo something" and once as "something: Foo" then I don't see how there's even a place for discussions that it's inconsistent. > Return types describe the

Re: AW: [PHP-DEV] Types on the right or on the left

Hi! >> "public Foo function bar()" would be so much worse than "public function >> bar() : Foo" > > Because when you grep for "function bar", in future you'd have to know > the return type too. Sorry, I do not understand - why to grep for "function bar" you'd have to know the type? Just grep for

Re: [PHP-DEV] Debugging code ...

On 04/11/14 16:25, Chris Wright wrote: > An 18 month release cycle for minors and over a decade since the last > major is hardly "daily". You do not need to update the libraries when > they start to use the new language features, but if you want to use the > new library features, and those features

Re: [PHP-DEV] Add a new flag for json_encode

On Tue, Nov 4, 2014 at 2:57 PM, Ferenc Kovacs wrote: > On Tue, Nov 4, 2014 at 4:13 AM, Juan Basso wrote: > > > Hi, > > > > I opened a pull request[1] in order to solve the bug 50224[2] and it > ended > > creating this pull request to add a new flag called > > JSON_PRESERVE_FRACTIONAL_PART on jso

Re: [PHP-DEV] Add a new flag for json_encode

On Tue, Nov 4, 2014 at 5:35 PM, Andrea Faulds wrote: > > > On 4 Nov 2014, at 14:57, Ferenc Kovacs wrote: > > > > Hi, > > > > just a slight correction: > > as far as I can tell, Jakus was ok with the general idea and even with > > turning this into the default, but he stated that it should only h

Re: [PHP-DEV] Add a new flag for json_encode

> On 4 Nov 2014, at 14:57, Ferenc Kovacs wrote: > > Hi, > > just a slight correction: > as far as I can tell, Jakus was ok with the general idea and even with > turning this into the default, but he stated that it should only happen in > a major version (as it would cause a slight BC, maybe thi

Re: [PHP-DEV] Annotation PHP 7

> On 4 Nov 2014, at 10:54, Benjamin Eberlei wrote: > > I agree with Stas that a much simpler approach is probably realistic. > > beginning pure speculation here, i see a short array like syntax like: > > [foo="bar", bar="baz", baz=["key": "value"]] > function annotated_fn() {} > > Maybe even

Re: [PHP-DEV] Types on the right or on the left

> On 4 Nov 2014, at 11:50, Chris Wright wrote: > > On 4 November 2014 10:32, Andrea Faulds wrote: > > > I thought it was inconsistent, but after discussions on StackOverflow, I > > don't think it actually is. > Return types describe the return type of a > > function, not the type of a functi

Re: [PHP-DEV] Debugging code ...

On 4 November 2014 16:07, Lester Caine wrote: > On 04/11/14 14:51, Kristopher wrote: > > Every IDE I've used has always working nicely with docblock > annotation > > and typing and has provided the facilities people seem to think > should > > be built in to PHP. > > > > You understand

Re: [PHP-DEV] Debugging code ...

On 04/11/14 14:45, Peter Lind wrote: > I'd suggest an alternative: fork PHP and only merge bugfixes in to your > own version. Best of both worlds, you get to keep your beloved PHP > pristine without any of the cumbersome new features, and the rest of us > can enjoy an evolving language. In hind si

Re: [PHP-DEV] Debugging code ...

On 04/11/14 14:51, Kristopher wrote: > Every IDE I've used has always working nicely with docblock annotation > and typing and has provided the facilities people seem to think should > be built in to PHP. > > You understand you don't have to use these new features, right? You can > co

Re: [PHP-DEV] Add a new flag for json_encode

On Tue, Nov 4, 2014 at 4:13 AM, Juan Basso wrote: > Hi, > > I opened a pull request[1] in order to solve the bug 50224[2] and it ended > creating this pull request to add a new flag called > JSON_PRESERVE_FRACTIONAL_PART on json_encode function. This flag will make > the json encode to output flo

Re: [PHP-DEV] Debugging code ...

On Tue Nov 04 2014 at 9:31:06 AM Lester Caine wrote: > > Every IDE I've used has always working nicely with docblock annotation > and typing and has provided the facilities people seem to think should > be built in to PHP. > You understand you don't have to use these new features, right? You can

Re: [PHP-DEV] Debugging code ...

It sounds like you're suggesting that all work on PHP that does not boil down to bug fixes be stopped. I'd suggest an alternative: fork PHP and only merge bugfixes in to your own version. Best of both worlds, you get to keep your beloved PHP pristine without any of the cumbersome new features, and

Re: [PHP-DEV] Debugging code ...

On 04/11/14 14:01, Florian Margaine wrote: > Hi, > > On Tue, Nov 4, 2014 at 2:28 PM, Lester Caine > wrote: > > On 04/11/14 13:13, Florian Margaine wrote: > > On the basis of 'If it's not broken', what is actually broken, > and what > > is just a

[PHP-DEV] [PATCH] Make *nix build system more similar to Windows

Currently under *nix, the build system uses a hardcoded location where the extension is: /ext/ext-name. Windows is just looking at where the the current config.w32 file is, takes the directory it is in and handles it like the root of the extension. Just simple, no hardcoded paths, just dependin

Re: [PHP-DEV] Debugging code ...

Hi, On Tue, Nov 4, 2014 at 2:28 PM, Lester Caine wrote: > On 04/11/14 13:13, Florian Margaine wrote: > > On the basis of 'If it's not broken', what is actually broken, and > what > > is just a matter of 'I don't like that way of working'? > > > > I have a working Annotation system th

Re: [PHP-DEV] Debugging code ...

On 04/11/14 13:13, Florian Margaine wrote: > On the basis of 'If it's not broken', what is actually broken, and what > is just a matter of 'I don't like that way of working'? > > I have a working Annotation system that has not changed since I started > working with PHP. PHPEclise s

AW: AW: [PHP-DEV] Types on the right or on the left

> I guess it's worth noting that my *personal* opinion is that I'd also rather > have the function return type declaration on the > left (I'd also like to drop the requirement for the "function" keyword in > method declarations), but since there are a number > of reasons why this no longer makes

Fwd: [PHP-DEV] Annotation PHP 7

Hi! > PHP7 has a wonderful parser, maybe it's possible to provide a general > syntax for annotations with userland hooks for arbitrary data. This > approach can give a tool for framework developers to define a node visitor > for annotations. Alternative way is to define simple key-value storage an

Re: [PHP-DEV] Debugging code ...

Hi, On Tue, Nov 4, 2014 at 2:03 PM, Lester Caine wrote: > On the basis of 'If it's not broken', what is actually broken, and what > is just a matter of 'I don't like that way of working'? > > I have a working Annotation system that has not changed since I started > working with PHP. PHPEclise s

[PHP-DEV] Debugging code ...

On the basis of 'If it's not broken', what is actually broken, and what is just a matter of 'I don't like that way of working'? I have a working Annotation system that has not changed since I started working with PHP. PHPEclise simple displays the information from the docblock comments and allows

Re: AW: [PHP-DEV] Types on the right or on the left

On 4 November 2014 12:17, Robert Stoll wrote: > > > -Ursprüngliche Nachricht- > > Von: are.you.winn...@gmail.com [mailto:are.you.winn...@gmail.com] Im > Auftrag von Chris Wright > > Gesendet: Dienstag, 4. November 2014 12:51 > > An: Andrea Faulds > > Cc: Stas Malyshev; Robert Stoll; PHP I

Re: [PHP-DEV] Annotation PHP 7

Hi! It would be nice to take "paving the walkways" approach, but last time > we tried, IIRC we've got into something very over-engineered. Maybe if > we try again with more restricted scope (i.e. not trying to put a DSL > for describing arbitrarily complex data structures into it :) it would > be

AW: AW: [PHP-DEV] Types on the right or on the left

> -Ursprüngliche Nachricht- > Von: are.you.winn...@gmail.com [mailto:are.you.winn...@gmail.com] Im Auftrag > von Chris Wright > Gesendet: Dienstag, 4. November 2014 12:51 > An: Andrea Faulds > Cc: Stas Malyshev; Robert Stoll; PHP Internals > Betreff: Re: AW: [PHP-DEV] Types on the right o

Re: AW: [PHP-DEV] Types on the right or on the left

On 4 November 2014 10:32, Andrea Faulds wrote: > > > On 4 Nov 2014, at 08:51, Stas Malyshev wrote: > > > > I agree, this is not a very good situation. It would be much better to > > take a systematic approach to this, but this is impossible since there > > is no systematic approach to strict typ

Re: [PHP-DEV] Annotation PHP 7

On Tue, Nov 4, 2014 at 12:20 PM, Pierre Joye wrote: > > On Nov 4, 2014 8:54 PM, "Benjamin Eberlei" wrote: > > > > On Tue, Nov 4, 2014 at 11:28 AM, Pierre Joye > wrote: > >> > >> On Tue, Nov 4, 2014 at 4:21 PM, Stas Malyshev > wrote: > >> > Hi! > >> > > >> >> As I do consider personal tastes im

Re: [PHP-DEV] Annotation PHP 7

On Nov 4, 2014 8:54 PM, "Benjamin Eberlei" wrote: > > On Tue, Nov 4, 2014 at 11:28 AM, Pierre Joye wrote: >> >> On Tue, Nov 4, 2014 at 4:21 PM, Stas Malyshev wrote: >> > Hi! >> > >> >> As I do consider personal tastes important, there are times where we should >> >> listen to our users. >> > >>

Re: [PHP-DEV] Annotation PHP 7

On Tue, Nov 4, 2014 at 11:28 AM, Pierre Joye wrote: > On Tue, Nov 4, 2014 at 4:21 PM, Stas Malyshev > wrote: > > Hi! > > > >> As I do consider personal tastes important, there are times where we > should > >> listen to our users. > > > > It would be nice to take "paving the walkways" approach, b

Re: [PHP-DEV] PHPDBG scope

On 04/11/14 09:37, Joe Watkins wrote: > On Tue, 2014-11-04 at 09:19 +, Lester Caine wrote: >> On 04/11/14 06:00, Joe Watkins wrote: >>> I'm not saying we should not extend the features of phpdbg, but, we >>> should do it knowing what it actually is, knowing that it is >>> fundamentally differen

Re: AW: [PHP-DEV] Types on the right or on the left

> On 4 Nov 2014, at 08:51, Stas Malyshev wrote: > > I agree, this is not a very good situation. It would be much better to > take a systematic approach to this, but this is impossible since there > is no systematic approach to strict typing in PHP, just some pieces here > and there. I think this

Re: [PHP-DEV] Annotation PHP 7

On Tue, Nov 4, 2014 at 4:21 PM, Stas Malyshev wrote: > Hi! > >> As I do consider personal tastes important, there are times where we should >> listen to our users. > > It would be nice to take "paving the walkways" approach, but last time > we tried, IIRC we've got into something very over-enginee

Re: AW: [PHP-DEV] Types on the right or on the left

On 4 November 2014 08:51, Stas Malyshev wrote: > I don't see why > "public Foo function bar()" would be so much worse than "public function > bar() : Foo" Because when you grep for "function bar", in future you'd have to know the return type too. I like to think of it as: function bar(): Type $

Re: [PHP-DEV] PHPDBG scope

On Tue, 2014-11-04 at 09:19 +, Lester Caine wrote: > On 04/11/14 06:00, Joe Watkins wrote: > > I'm not saying we should not extend the features of phpdbg, but, we > > should do it knowing what it actually is, knowing that it is > > fundamentally different to xdebug. > > Having just hit another

Re: [PHP-DEV] Annotation PHP 7

Hi! > As I do consider personal tastes important, there are times where we should > listen to our users. It would be nice to take "paving the walkways" approach, but last time we tried, IIRC we've got into something very over-engineered. Maybe if we try again with more restricted scope (i.e. not

Re: [PHP-DEV] PHPDBG scope

On 04/11/14 06:00, Joe Watkins wrote: > I'm not saying we should not extend the features of phpdbg, but, we > should do it knowing what it actually is, knowing that it is > fundamentally different to xdebug. Having just hit another 'white screen' problem on a site I'm trying to update, I do wonder

Re: AW: [PHP-DEV] Types on the right or on the left

Hi! > put types only on the right, or only on the left or mix it. I > followed the return type RFC and thus know that many people think it > has to be on the left hand side. Fair enough, I do not have anything > against such a decision. I also have nothing against putting the type > on the right h

AW: [PHP-DEV] Types on the right or on the left

> -Ursprüngliche Nachricht- > Von: Andrea Faulds [mailto:a...@ajf.me] > Gesendet: Montag, 3. November 2014 16:40 > An: Robert Stoll > Cc: PHP Internals > Betreff: Re: [PHP-DEV] Types on the right or on the left > > > > On 3 Nov 2014, at 15:07, Robert Stoll wrote: > > > > It adds the type

Re: [PHP-DEV] [RFC][Vote] Return Types

Le 04/11/2014 09:37, Christoph Becker a écrit : Ivan Enderlin @ Hoa wrote: Excellent RFC, thank you. However, there is no mention about using `static`, `self` or `parent` as a type (it is possible for an argument). Something like: ```php class Singleton { public function getInstance ( $x

Re: [PHP-DEV] [RFC][Vote] Return Types

Ivan Enderlin @ Hoa wrote: > Excellent RFC, thank you. However, there is no mention about using > `static`, `self` or `parent` as a type (it is possible for an argument). > Something like: > ```php > class Singleton { > > public function getInstance ( $x, $y): static { … } > } > ``` > Maybe I

AW: [PHP-DEV] Types on the right or on the left

> -Ursprüngliche Nachricht- > Von: morrison.l...@gmail.com [mailto:morrison.l...@gmail.com] Im Auftrag von > Levi Morrison > Gesendet: Montag, 3. November 2014 19:54 > An: Robert Stoll > Cc: PHP Internals > Betreff: Re: [PHP-DEV] Types on the right or on the left > > > Thoughts? > > I th

Re: [PHP-DEV] [RFC][Vote] Return Types

Le 04/11/2014 03:01, Levi Morrison a écrit : Dear Internals, I am pleased to announce that the return type RFC is now open for voting[1]. Note that the implementation needs a bit of cleaning up before merging should the RFC be accepted; Dmitry has already volunteered to help with that, but more