Re: [PHP-DEV] Compile problems - Was Switch jumptable optimization

2015-02-18 Thread Sebastian Bergmann
Am 17.02.2015 um 10:51 schrieb Lester Caine: > It seems not even running distclean clears down everything that needs > removing for some of the changes currently going through. ./vcsclean I stopped using distclean / vcsclean a while ago. "git clean -xdf" does the trick for me. -- PHP Internals

Re: [PHP-DEV] Annotations in PHP7

2015-02-18 Thread Benjamin Eberlei
On Wed, Feb 18, 2015 at 8:02 AM, Dmitry Stogov wrote: > > > On Wed, Feb 18, 2015 at 12:51 AM, guilhermebla...@gmail.com < > guilhermebla...@gmail.com> wrote: > >> François, >> >> Doctrine relies on nested annotations for a variety of mapping >> information. >> One example: >> >> >> http://doctrin

Re: [PHP-DEV] Reviving scalar type hints

2015-02-18 Thread Stanislav Malyshev
Hi! > So let's talk compromise. > Would leaving internal functions out of the picture at this stage > change you mind? This is effectively what Hack does, internal > functions are explicitly marked as "coercible". For me, the option that makes users remember which functions are internal and whic

Re: [PHP-DEV] Annotations in PHP7

2015-02-18 Thread Dmitry Stogov
On Wed, Feb 18, 2015 at 11:05 AM, Benjamin Eberlei wrote: > > > On Wed, Feb 18, 2015 at 8:02 AM, Dmitry Stogov wrote: > >> >> >> On Wed, Feb 18, 2015 at 12:51 AM, guilhermebla...@gmail.com < >> guilhermebla...@gmail.com> wrote: >> >>> François, >>> >>> Doctrine relies on nested annotations for a

Re: [PHP-DEV] Annotations in PHP7

2015-02-18 Thread Derick Rethans
On Tue, 17 Feb 2015, Dmitry Stogov wrote: > On Mon, Feb 16, 2015 at 10:57 PM, Derick Rethans wrote: > > > On Mon, 16 Feb 2015, Dmitry Stogov wrote: > > > > > hi, > > > > > > During discussion of different ways of implementing "Design by Contract" > > we > > > got an idea of using annotations. >

Re: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread Andrey Andreev
Hi, On Wed, Feb 18, 2015 at 9:00 AM, Zeev Suraski wrote: >> -Original Message- >> From: Nikita Popov [mailto:nikita@gmail.com] >> Sent: Wednesday, February 18, 2015 3:06 AM >> To: Rasmus Lerdorf >> Cc: Sara Golemon; PHP internals >> Subject: Re: [PHP-DEV] Scalar Type Hints v0.4 >> >>

Re: [PHP-DEV] RFC Proposal

2015-02-18 Thread Tim Bezhashvyly
Dear internals, my RFC was not about dropping just class constants but constants in general. Now I realise that you are not ready for this and most likely will never be. Thus I’m withdrawing my proposal. Regards, Tim > On 18 Feb 2015, at 06:59, Dmitry Stogov wrote: > > > > On Tue, Feb 17,

Re: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread Lester Caine
On 18/02/15 09:14, Andrey Andreev wrote: > That is especially bad when such identifiers are in fact generated as > integers first so that they are incremental, but the > program/database/business logic requires them to be fixed-length > strings and/or in hexadecimal format. In such cases, even sile

Re: [PHP-DEV] Compile problems - Was Switch jumptable optimization

2015-02-18 Thread Lester Caine
On 18/02/15 08:02, Sebastian Bergmann wrote: >> It seems not even running distclean clears down everything that needs >> > removing for some of the changes currently going through. ./vcsclean > I stopped using distclean / vcsclean a while ago. "git clean -xdf" > does the trick for me. hg purge /

Re: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread Andrey Andreev
Hi, On Wed, Feb 18, 2015 at 11:54 AM, Lester Caine wrote: > On 18/02/15 09:14, Andrey Andreev wrote: >> That is especially bad when such identifiers are in fact generated as >> integers first so that they are incremental, but the >> program/database/business logic requires them to be fixed-length

Re: [PHP-DEV] [RFC] Exceptions in the engine

2015-02-18 Thread Tony Marston
"Rowan Collins" wrote in message news:54e32caa.5030...@gmail.com... Tony Marston wrote on 17/02/2015 09:59: "Rowan Collins" wrote in message news:54e1c993.1070...@gmail.com... Tony Marston wrote on 16/02/2015 10:09: This RFC only mentions errors with object methods, so what impact would it

Re: [PHP-DEV] [RFC] Exceptions in the engine

2015-02-18 Thread Nikita Nefedov
On 18 Feb 2015 13:53, "Tony Marston" wrote: > > Could it be restricted to the current scope? In your example the call to fopen() exists in the load_data() function and is not in a try ... catch block within *that* function, so the fact that the call to load_data() is within a try ... catch block s

Re: [PHP-DEV] Annotations in PHP7

2015-02-18 Thread Dmitry Stogov
On Wed, Feb 18, 2015 at 11:59 AM, Derick Rethans wrote: > On Tue, 17 Feb 2015, Dmitry Stogov wrote: > > > On Mon, Feb 16, 2015 at 10:57 PM, Derick Rethans wrote: > > > > > On Mon, 16 Feb 2015, Dmitry Stogov wrote: > > > > > > > hi, > > > > > > > > During discussion of different ways of implement

RE: [PHP-DEV] RFC Proposal

2015-02-18 Thread François Laupretre
Hi Tim, As I already told you, you should proceed step by step. Implementing immutable properties *and* removing constants is just a too big step. And, IMO, one may pass, while the second one has no chance, especially if you propose to remove PHP constants as well as class constants, without a

AW: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread Robert Stoll
> -Ursprüngliche Nachricht- > Von: Zeev Suraski [mailto:z...@zend.com] > Gesendet: Mittwoch, 18. Februar 2015 08:00 > An: Nikita Popov; Rasmus Lerdorf > Cc: Sara Golemon; PHP internals > Betreff: RE: [PHP-DEV] Scalar Type Hints v0.4 > > > -Original Message- > > From: Nikita Popov [

Re: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread Michael Wallner
On 17/02/15 23:03, Sara Golemon wrote: > 1) Introduce scalar types for primitives: bool, int, float, string, > resource, object (we already have array) > 1a) Introduce meta-types as pre-defined unions (we can add custom > unions in a later rfc). A possible list may be as follows (again, we > can

Re: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread Rowan Collins
Nikita Popov wrote on 18/02/2015 00:35: I don't like the way this is heading with regards to internal functions. Apart from better inter-compatibility, the primary appeal of Andrea's proposal was that we have the option to make not only userland function calls strict, but internal ones as well. W

Re: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread Rowan Collins
Michael Wallner wrote on 18/02/2015 11:19: On 17/02/15 23:03, Sara Golemon wrote: 1) Introduce scalar types for primitives: bool, int, float, string, resource, object (we already have array) 1a) Introduce meta-types as pre-defined unions (we can add custom unions in a later rfc). A possible li

Re: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread Michael Wallner
On 18/02/15 12:31, Rowan Collins wrote: > Michael Wallner wrote on 18/02/2015 11:19: >> On 17/02/15 23:03, Sara Golemon wrote: >> >>> 1) Introduce scalar types for primitives: bool, int, float, string, >>> resource, object (we already have array) >>> 1a) Introduce meta-types as pre-defined unions (

Re: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread Rowan Collins
Michael Wallner wrote on 18/02/2015 11:39: On 18/02/15 12:31, Rowan Collins wrote: Michael Wallner wrote on 18/02/2015 11:19: On 17/02/15 23:03, Sara Golemon wrote: 1) Introduce scalar types for primitives: bool, int, float, string, resource, object (we already have array) 1a) Introduce meta-

RE: [PHP-DEV] Annotations in PHP7

2015-02-18 Thread François Laupretre
Hi Dmitry, > De : Dmitry Stogov [mailto:dmi...@zend.com] > Nested annotations are not going to be necessary, because they may be > represented by PHP pseudo-syntax (and/or PHP array syntax) > > ManyToMany($targetEntity="Phonenumber"), > JoinTable($name="users_phonenumbers", > $jo

RE: [PHP-DEV] Annotations in PHP7

2015-02-18 Thread François Laupretre
> De : Benjamin Eberlei [mailto:kont...@beberlei.de] > > nested can be done in any way, its a statement so the following would work: > > [new JoinColumn('id', 'other_id')]]))> Dmitry is planning compile time evaluation, which is probably the only way to do it if we use PHP expressions. Is class

Re: [PHP-DEV] Annotations in PHP7

2015-02-18 Thread Dmitry Stogov
On Wed, Feb 18, 2015 at 3:01 PM, François Laupretre wrote: > > De : Benjamin Eberlei [mailto:kont...@beberlei.de] > > > > nested can be done in any way, its a statement so the following would > work: > > > > [new JoinColumn('id', > 'other_id')]]))> > > Dmitry is planning compile time evaluation,

[PHP-DEV] Nightmares on type hints, annotations, and aop...

2015-02-18 Thread Bishop Bettini
After a spate of literal coding nightmares, I woke needing to commit these thoughts to the list. These may have been raised before, I can't remember, these debate has been raging for so long. THING 1: Hints are just is_* wrappers function f(scalar $s, int $i) { } effectively is sugar for: fun

RE: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread François Laupretre
Hi Andrey, > De : Andrey Andreev [mailto:n...@devilix.net] > > I too am curious about the potential issue with "123" to 123 > specifically, although it could be seen as a subset of another problem > that is solved with strict hints - numeric-character string > identifiers being erroneously treated

RE: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread Zeev Suraski
> Consider the following signature: > > function foo(int $bar) {} > > In the case of a *string* representation of a hexadecimal number, the > following would error only on the last iteration with a weak hint, and on > the > very first if it was a strict hint: > > for ($i = 0; $i < 11; $i++)

RE: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread François Laupretre
Hi, > > Octal is something that can often be miss converted since it IS the same > as an integer with only a '0' in front in PHP. But that is not something > that can be fixed with the current proposals? What do you propose ? Considering leading zero as octal indicator is not an option, IMO. If y

Re: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread Andrey Andreev
Hi, On Wed, Feb 18, 2015 at 2:27 PM, François Laupretre wrote: > Hi Andrey, > >> De : Andrey Andreev [mailto:n...@devilix.net] >> >> I too am curious about the potential issue with "123" to 123 >> specifically, although it could be seen as a subset of another problem >> that is solved with strict

Re: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread Lazare Inepologlou
2015-02-18 12:45 GMT+01:00 Rowan Collins : > Michael Wallner wrote on 18/02/2015 11:39: > >> On 18/02/15 12:31, Rowan Collins wrote: >> >>> Michael Wallner wrote on 18/02/2015 11:19: >>> On 17/02/15 23:03, Sara Golemon wrote: 1) Introduce scalar types for primitives: bool, int, flo

RE: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread François Laupretre
> De : Andrey Andreev [mailto:n...@devilix.net] > > Consider the following signature: > > function foo(int $bar) {} > > In the case of a *string* representation of a hexadecimal number, the > following would error only on the last iteration with a weak hint, and > on the very first if it was

RE: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread Zeev Suraski
> -Original Message- > From: Robert Stoll [mailto:p...@tutteli.ch] > Sent: Wednesday, February 18, 2015 1:14 PM > To: 'Zeev Suraski'; 'Nikita Popov'; 'Rasmus Lerdorf' > Cc: 'Sara Golemon'; 'PHP internals' > Subject: AW: [PHP-DEV] Scalar Type Hints v0.4 > > > -Ursprüngliche Nachricht

Re: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread Andrey Andreev
Hi Zeev, On Wed, Feb 18, 2015 at 2:31 PM, Zeev Suraski wrote: >> Consider the following signature: >> >> function foo(int $bar) {} >> >> In the case of a *string* representation of a hexadecimal number, the >> following would error only on the last iteration with a weak hint, and on >> the >>

Re: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread Leigh
On 17 February 2015 at 22:03, Sara Golemon wrote: > Based on conversations here and elsewhere on the internet, I'd like to > put forward a rough gameplan for scalar types which I hope addresses > most concerns. This is back-of-the-napkin and I'm not asking for a > committed yes/no, just pre-rfc s

Re: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread Rowan Collins
Leigh wrote on 18/02/2015 13:10: 3b) Internal impact: Again, behavior remains unchanged unless the >ZEND_ARG_INFO struct has been modified to add proper typehints. If >typehints have been added, then the more aggressive coersion rules >apply during typehint validation. This leaves us in a state

RE: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread François Laupretre
> De : Robert Stoll [mailto:p...@tutteli.ch] > > Strict mode is useful in the sense that it prevents unnecessary implicit > conversions (which are costly) and it improves readability. > Following an example: > > function foo(string $x, int $y){ > bar(1); > return strstr($x,"hello", $y); > } >

Re: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread Leigh
On 18 February 2015 at 13:18, Rowan Collins wrote: >> This leaves us in a state where some functions will have defined types >> with their aggressive coersion rules and some will not, and we can't >> expect users to remember which set of functions have been updated or >> not. > > That's precisely

Re: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread Andrey Andreev
Hi François, On Wed, Feb 18, 2015 at 3:02 PM, François Laupretre wrote: >> De : Andrey Andreev [mailto:n...@devilix.net] >> >> Consider the following signature: >> >> function foo(int $bar) {} >> >> In the case of a *string* representation of a hexadecimal number, the >> following would error

RE: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread François Laupretre
Hi Michael, The case of null is a little special. As a type hint, we need it for return and union types only. Considering union types, they were clearly left out of scope for 7.0 and I personally won't propose pre-defined union types before the general case for unions is designed. Conversion t

RE: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread François Laupretre
Hi Nikita, > > I don't like the way this is heading with regards to internal functions. > Apart from better inter-compatibility, the primary appeal of Andrea's > proposal was that we have the option to make not only userland function > calls strict, but internal ones as well. With these modificatio

Re: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread Rowan Collins
Leigh wrote on 18/02/2015 13:31: On 18 February 2015 at 13:18, Rowan Collins wrote: This leaves us in a state where some functions will have defined types with their aggressive coersion rules and some will not, and we can't expect users to remember which set of functions have been updated or no

Re: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread Lester Caine
On 18/02/15 12:33, François Laupretre wrote: >> Octal is something that can often be miss converted since it IS the same >> > as an integer with only a '0' in front in PHP. But that is not something >> > that can be fixed with the current proposals? > What do you propose ? Considering leading zero

Re: [PHP-DEV] RFC: Expectations

2015-02-18 Thread Nikita Popov
On Tue, Feb 17, 2015 at 10:50 PM, Dmitry Stogov wrote: > Hi Joe > > The patch is ready https://github.com/php/php-src/pull/1088/files > > 1) I implemented AST pretty-printer to reconstruct the source. It may be > reused in Reflection and other places through > > ZEND_API zend_string *zend_ast_exp

Re: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread Leigh
On 18 February 2015 at 14:40, Lester Caine wrote: > But my favourite is still > '\143\141\164' == "\143\141\164" which is false, but I doubt many would > know why? Pretty sure one of the first things PHP devs learn is that single quoted strings only accept \' and \\ as escape sequences. -- PHP

Re: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread Pádraic Brady
Hi all, On 18 February 2015 at 09:14, Andrey Andreev wrote: > Hi, > > On Wed, Feb 18, 2015 at 9:00 AM, Zeev Suraski wrote: >> I am wondering what the point is indeed with preventing "123" to 123. So >> far, all the concrete use cases people brought up had to do with "Apple" or >> "100 dogs", bu

RE: [PHP-DEV] Nightmares on type hints, annotations, and aop...

2015-02-18 Thread François Laupretre
Hi Bishop, > De : bishop.bett...@gmail.com [mailto:bishop.bett...@gmail.com] De la part de > Bishop Bettini > > THING 1: Hints are just is_* wrappers Wrong. Only *strict* types are. > THING 2: Hints are truthy callables > > function my_mixed($m) { > return (null === $m || is_string($m)); >

AW: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread Robert Stoll
> -Ursprüngliche Nachricht- > Von: Zeev Suraski [mailto:z...@zend.com] > Gesendet: Mittwoch, 18. Februar 2015 14:03 > An: Robert Stoll > Cc: Sara Golemon; PHP internals > Betreff: RE: [PHP-DEV] Scalar Type Hints v0.4 > > > -Original Message- > > From: Robert Stoll [mailto:p...@tutt

Re: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread Pádraic Brady
On 18 February 2015 at 13:30, François Laupretre wrote: > Actually, your example is partially invalid because strict-typing radicals > now propose to add a (int -> float) exception to so-called strict mode (which > proves the approach is flawed, IMHO). Careful, it helps not to call folk "radic

Re: [PHP-DEV] [RFC][Discussion] Parser extension API

2015-02-18 Thread Nikita Popov
On Wed, Feb 18, 2015 at 7:22 AM, Dmitry Stogov wrote: > Hi, > > On Tue, Feb 17, 2015 at 2:46 PM, Alexander Lisachenko < > lisachenko...@gmail.com> wrote: > >> Hello, internals! >> >> I want to introduce a RFC for providing a userland API for accessing an >> Abstract Syntax Tree of the source code

Re: [PHP-DEV] [RFC][Discussion] Parser extension API

2015-02-18 Thread Cesar Rodas
On 18/02/15 15:59, Nikita Popov wrote: > On Wed, Feb 18, 2015 at 7:22 AM, Dmitry Stogov wrote: > >> Hi, >> >> On Tue, Feb 17, 2015 at 2:46 PM, Alexander Lisachenko < >> lisachenko...@gmail.com> wrote: >> >>> Hello, internals! >>> >>> I want to introduce a RFC for providing a userland API for acce

RE: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread Zeev Suraski
> -Original Message- > From: Pádraic Brady [mailto:padraic.br...@gmail.com] > Sent: Wednesday, February 18, 2015 4:50 PM > To: Andrey Andreev > Cc: Zeev Suraski; Nikita Popov; Rasmus Lerdorf; Sara Golemon; PHP > internals > Subject: Re: [PHP-DEV] Scalar Type Hints v0.4 > > Hi all, > > On 18

RE: [PHP-DEV] Annotations in PHP7

2015-02-18 Thread François Laupretre
Hi Dmitry, Right. That’s what I got from your last reply. But my question was about another post where you are talking about ‘compile time evaluation’ of expressions, which is different from the bare key/value storage I understood first, and poses the problem of compile time evaluation scope

Re: [PHP-DEV] [RFC][Discussion] Parser extension API

2015-02-18 Thread Nikita Popov
On Wed, Feb 18, 2015 at 4:06 PM, Cesar Rodas wrote: > > On 18/02/15 15:59, Nikita Popov wrote: > > On Wed, Feb 18, 2015 at 7:22 AM, Dmitry Stogov wrote: > > > >> Hi, > >> > >> On Tue, Feb 17, 2015 at 2:46 PM, Alexander Lisachenko < > >> lisachenko...@gmail.com> wrote: > >> > >>> Hello, internals

Re: [PHP-DEV] [RFC][Discussion] Parser extension API

2015-02-18 Thread Alexander Lisachenko
2015-02-18 17:59 GMT+03:00 Nikita Popov : > Alexander, I would recommend you to split this into two RFCs, one dealing > only with AST export (and maybe pretty printing) and the second one with > the compilation hooks. There's probably a few questions about the export > API that should be discussed

RE: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread François Laupretre
> De : Lazare Inepologlou [mailto:linep...@gmail.com] > > So, yes it would be nice null not to be included in scalars. Instead, we > could have a union type like scalar? = scalar|null That's roughly the idea. However, IMO, the general mechanism for union types needs to be defined before we start

Re: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread Lester Caine
On 18/02/15 14:59, Pádraic Brady wrote: > I wouldn't necessarily mind int->float - it's lossless assuming one way only. Assuming int is not 64 bit ;) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.

RE: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread François Laupretre
> De : Leigh [mailto:lei...@gmail.com] > > Can we keep a 0) of "reserve names for future use in-case of RFC > failure" option. Reserving names is only needed as long as we keep keywords sharing the same naming space as classes. This is a mistake from the past and, as long as we keep it, each new

RE: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread François Laupretre
> De : Rowan Collins [mailto:rowan.coll...@gmail.com] > That's precisely the case for every existing user-defined function. > Switching to PHP 7 won't suddenly add type hints to every function in > every library and every existing bespoke code base, so there is no way > to avoid that thought proces

Re: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread Patrick ALLAERT
Hi Sara (and thanks for continuing the work!) Le Tue Feb 17 2015 at 23:04:20, Sara Golemon a écrit : [...] > 2) Define a way to enable "strict mode" (we'll be weak by default). > [...] > 3) Tighten up coersion rules for weak mode. i.e. "10 dogs" for an int > is a violation, but "10" is accepta

RE: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread François Laupretre
> De : Zeev Suraski [mailto:z...@zend.com] > > If we do implement the single-mode, stricter-than-pure-weak and > weaker-than-pure-strict ruleset, we could introduce a new set of conversion > functions, along the lines of safe_int(), that would follow the same rules > as the corresponding type hints

RE: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread François Laupretre
> De : Pádraic Brady [mailto:padraic.br...@gmail.com] > > However, “123” is exceptional. It’s redefining an integer as “ an > integer or a string comprised wholly of digits without leading zeroes, > with an optional leading hyphen, and representing an integer up to > PHP_INT_MAX” Add leading zeros

Re: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread Pierre Joye
On Tue, Feb 17, 2015 at 5:05 PM, Nikita Popov wrote: > On Wed, Feb 18, 2015 at 1:53 AM, Rasmus Lerdorf wrote: > >> On 02/17/2015 04:35 PM, Nikita Popov wrote: >> > I don't buy into Rasmus arguments about internal functions. They concern >> > one particular edge case (int->float coercion) and I do

Re: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread Rowan Collins
François Laupretre wrote on 18/02/2015 15:47: De : Leigh [mailto:lei...@gmail.com] Can we keep a 0) of "reserve names for future use in-case of RFC failure" option. Reserving names is only needed as long as we keep keywords sharing the same naming space as classes. This is a mistake from the p

RE: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread François Laupretre
> De : Pádraic Brady [mailto:padraic.br...@gmail.com] > > Careful, it helps not to call folk "radicals" if you intend to pursue > a compromise with them ;). Sorry, english is not my native language, and 'radical' may be offensive. I was just looking for a word for people who consider providing tw

Re: [PHP-DEV] Annotations in PHP7

2015-02-18 Thread Dmitry Stogov
On Wed, Feb 18, 2015 at 6:14 PM, François Laupretre wrote: > Hi Dmitry, > > > > Right. That’s what I got from your last reply. But my question was about > another post where you are talking about ‘compile time evaluation’ of > expressions, which is different from the bare key/value storage I > un

RE: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread François Laupretre
> De : Zeev Suraski [mailto:z...@zend.com] > > That means that "42" can coerce into int, and "42.2" can coerce into float, > and int can coerce into float - but not vice versa. I was wondering : should we systematically reject float to int, or should we accept it when range fits and fractional pa

RE: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread François Laupretre
> De : Patrick ALLAERT [mailto:patrickalla...@php.net] > ini_set("coercion_reporting", COERCION_ERROR); // Fail in case of > potentially bad coercion > > foo(7); > // int(7) > foo("7"); > // int(7) > foo("7 dogs"); > // Catchable fatal error: Unsafe coercion transformin

Re: [PHP-DEV] RFC: Expectations

2015-02-18 Thread Dmitry Stogov
On Wed, Feb 18, 2015 at 5:44 PM, Nikita Popov wrote: > On Tue, Feb 17, 2015 at 10:50 PM, Dmitry Stogov wrote: > >> Hi Joe >> >> The patch is ready https://github.com/php/php-src/pull/1088/files >> >> 1) I implemented AST pretty-printer to reconstruct the source. It may be >> reused in Reflection

Re: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread Rasmus Lerdorf
On 02/18/2015 08:51 AM, François Laupretre wrote: >> De : Pádraic Brady [mailto:padraic.br...@gmail.com] >> >> Careful, it helps not to call folk "radicals" if you intend to pursue >> a compromise with them ;). > > Sorry, english is not my native language, and 'radical' may be offensive. > > I wa

Re: [PHP-DEV] [RFC][Discussion] Parser extension API

2015-02-18 Thread Jared Williams
On Wed, 2015-02-18 at 16:17 +0100, Nikita Popov wrote: > On Wed, Feb 18, 2015 at 4:06 PM, Cesar Rodas wrote: > > > > > On 18/02/15 15:59, Nikita Popov wrote: > > > On Wed, Feb 18, 2015 at 7:22 AM, Dmitry Stogov wrote: > > > > > >> Hi, > > >> > > >> On Tue, Feb 17, 2015 at 2:46 PM, Alexander Lisa

Re: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread Zeev Suraski
> On 18 בפבר׳ 2015, at 19:50, Rasmus Lerdorf wrote: > > On 02/18/2015 08:51 AM, François Laupretre wrote: >>> De : Pádraic Brady [mailto:padraic.br...@gmail.com] >>> >>> Careful, it helps not to call folk "radicals" if you intend to pursue >>> a compromise with them ;). >> >> Sorry, english is

RE: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread François Laupretre
> De : Rowan Collins [mailto:rowan.coll...@gmail.com] > > What if we defined the types as names in the \PHP namespace, but defined > a slightly different algorithm for resolving typehints vs other uses: > > function foo(\PHP\types\numeric $a) // unambiguous but unwieldy > function foo(\My\Namespac

Re: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread Sara Golemon
On Wed, Feb 18, 2015 at 7:34 AM, Patrick ALLAERT wrote: > Regarding 2) and 3): > An option might be to implement "weak mode" only and configure the coercion > rules "reporting" in a similar way than with the error_reporting > configuration entry. > > ini_set("coercion_reporting", 0); // curren

RE: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread François Laupretre
> De : Patrick ALLAERT [mailto:patrickalla...@php.net] > > The biggest advantage, IMHO, is that you get the exact same result whether > you do: > > foo((int) $value); > > or: > > foo($value); > > ... whatever the mode you are in. Wrong. Parameter parsing rules are much more restrictive

Re: [PHP-DEV] Annotations in PHP7

2015-02-18 Thread guilhermebla...@gmail.com
Hi Dmitry, > Are you (and Doctrine team) interested in this annotation idea? I'd say that Benjamin nailed in our possible usage: class Foo { } Now I do feel we need to elaborate some sort of named parameters. Doctrine tries to simplify a lot developer's life by using consistency in default map

Re: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread Lester Caine
On 18/02/15 17:55, Zeev Suraski wrote: > We can limit ourselves to values below that limit. If you deal with values > above it, be explicit about casting. This is exactly my problem ... Databases are using 64bit primary keys more and more, and having to worry about going over some limit is the ve

Re: [PHP-DEV] [RFC][Discussion] Parser extension API

2015-02-18 Thread Nikita Popov
On Wed, Feb 18, 2015 at 4:22 PM, Alexander Lisachenko < lisachenko...@gmail.com> wrote: > > 2015-02-18 17:59 GMT+03:00 Nikita Popov : > >> Alexander, I would recommend you to split this into two RFCs, one dealing >> only with AST export (and maybe pretty printing) and the second one with >> the co

Re: [PHP-DEV] [RFC][Discussion] Parser extension API

2015-02-18 Thread Dmitry Stogov
I think the AST API shouldn't use "public" properties. Using it, we will have to construct the whole tree of objects, duplicating information from AST. I would propose SimpleXML approach instead - construct object only for node(s) we currently access. So at first we will construct just single obje

Re: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread Rowan Collins
François Laupretre wrote on 18/02/2015 18:05: De : Rowan Collins [mailto:rowan.coll...@gmail.com] What if we defined the types as names in the \PHP namespace, but defined a slightly different algorithm for resolving typehints vs other uses: function foo(\PHP\types\numeric $a) // unambiguous but

Re: [PHP-DEV] Re: [RFC] Exceptions in the engine

2015-02-18 Thread Dan Ackroyd
On 13 February 2015 at 23:25, Nikita Popov wrote: > Subclassing: Should there be more specific subclasses of EngineException > for particular errors? It's not obvious that any subclasses would be useful. However using the code to specify the exact type of error, rather than having to inspect the

Re: [PHP-DEV] [RFC][Discussion] Parser extension API

2015-02-18 Thread Alexander Lisachenko
> I'm okay with having stuff like ->getKindName() on the nodes, however I'd > still keep around the free-standing functions, because they can be used > without a node (i.e. you only need the kind AST_FOO and not an instantiated > node). I think that getting name of kind is useless without value o

Re: [PHP-DEV] [RFC][Discussion] Parser extension API

2015-02-18 Thread Alexander Lisachenko
2015-02-18 22:22 GMT+03:00 Dmitry Stogov : > I think the AST API shouldn't use "public" properties. > Using it, we will have to construct the whole tree of objects, duplicating > information from AST. > I would propose SimpleXML approach instead - construct object only for > node(s) we currently a

Re: [PHP-DEV] [RFC][Discussion] Parser extension API

2015-02-18 Thread Alexander Lisachenko
I want to attach a link to the Python AST documentation: https://docs.python.org/3.2/library/ast.html What I like there is iteration of nodes with generators (yields). NodeVisitor that can be extended and used as coroutine to simplify logic of traversal. I want to keep Node class as simple DTO wit

Re: [PHP-DEV] [RFC][Discussion] Parser extension API

2015-02-18 Thread Nikita Popov
On Wed, Feb 18, 2015 at 8:22 PM, Dmitry Stogov wrote: > I think the AST API shouldn't use "public" properties. > Using it, we will have to construct the whole tree of objects, duplicating > information from AST. > I would propose SimpleXML approach instead - construct object only for > node(s) we

Re: [PHP-DEV] [RFC][Discussion] Parser extension API

2015-02-18 Thread Dmitry Stogov
On Wed, Feb 18, 2015 at 10:34 PM, Alexander Lisachenko < lisachenko...@gmail.com> wrote: > > 2015-02-18 22:22 GMT+03:00 Dmitry Stogov : > >> I think the AST API shouldn't use "public" properties. >> Using it, we will have to construct the whole tree of objects, >> duplicating information from AST.

Re: [PHP-DEV] [RFC][Discussion] Parser extension API

2015-02-18 Thread Dmitry Stogov
On Wed, Feb 18, 2015 at 11:00 PM, Nikita Popov wrote: > On Wed, Feb 18, 2015 at 8:22 PM, Dmitry Stogov wrote: > >> I think the AST API shouldn't use "public" properties. >> Using it, we will have to construct the whole tree of objects, >> duplicating information from AST. >> I would propose Simp

Re: [PHP-DEV] Annotations in PHP7

2015-02-18 Thread Pavel Kouřil
On Wed, Feb 18, 2015 at 7:28 PM, guilhermebla...@gmail.com wrote: > Hi Dmitry, > >> Are you (and Doctrine team) interested in this annotation idea? > > I'd say that Benjamin nailed in our possible usage: > > > class Foo { > } > > Now I do feel we need to elaborate some sort of named parameters. D

RE: [PHP-DEV] Annotations in PHP7

2015-02-18 Thread François Laupretre
Hi Guilherme, > De : guilhermebla...@gmail.com [mailto:guilhermebla...@gmail.com] > [ > new OneToOne("Address"), > new JoinColumn(default, default, default, default, "CASCADE") > ] > )> > public $address; Why not : "Address", 'JoinColumns' => [ [ 'onDele

[PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5

2015-02-18 Thread Anthony Ferrara
Dear Internals, Since the resignation of Andrea, the mixed-mode type hint (called declaration in the proposal) proposal has been left abandoned. Considering that the ending votes were 67/34 (66.3%) with several no-votes being only due to reasonably minor issues with the proposal, I would like to r

Re: [PHP-DEV] Annotations in PHP7

2015-02-18 Thread Benjamin Eberlei
On Wed, Feb 18, 2015 at 9:29 PM, Pavel Kouřil wrote: > On Wed, Feb 18, 2015 at 7:28 PM, guilhermebla...@gmail.com > wrote: > > Hi Dmitry, > > > >> Are you (and Doctrine team) interested in this annotation idea? > > > > I'd say that Benjamin nailed in our possible usage: > > > > > > class Foo {

Re: [PHP-DEV] Annotations in PHP7

2015-02-18 Thread Benjamin Eberlei
On Wed, Feb 18, 2015 at 9:40 PM, François Laupretre wrote: > Hi Guilherme, > > > De : guilhermebla...@gmail.com [mailto:guilhermebla...@gmail.com] > > > [ > > new OneToOne("Address"), > > new JoinColumn(default, default, default, default, "CASCADE") > > ] > > )> > > publi

Re: [PHP-DEV] [RFC] Exceptions in the engine

2015-02-18 Thread Rowan Collins
Tony Marston wrote on 18/02/2015 10:52: "Rowan Collins" wrote in message news:54e32caa.5030...@gmail.com... Tony Marston wrote on 17/02/2015 09:59: "Rowan Collins" wrote in message news:54e1c993.1070...@gmail.com... Tony Marston wrote on 16/02/2015 10:09: This RFC only mentions errors with

Re: [PHP-DEV] RFC Proposal

2015-02-18 Thread Benoit Schildknecht
Hi Tim, Le Wed, 18 Feb 2015 10:44:20 +0100, Tim Bezhashvyly a écrit: Dear internals, my RFC was not about dropping just class constants but constants in general. Now I realise that you are not ready for this and most likely will never be. Thus I’m withdrawing my proposal. Regards, Ti

RE: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread François Laupretre
> De : Rowan Collins [mailto:rowan.coll...@gmail.com] > > They'd use whatever (non-reserved) namespace the implementer wanted. > e.g. > > namespace Symfony\Component\TypeChecking; > > basicType nonNegativeInt extends PHP\types\int { > public function isValid(int $value) { > return

Re: [PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5

2015-02-18 Thread Leigh
On 18 February 2015 at 20:44, Anthony Ferrara wrote: > Dear Internals, > > Since the resignation of Andrea, the mixed-mode type hint (called > declaration in the proposal) proposal has been left abandoned. > Considering that the ending votes were 67/34 (66.3%) with several > no-votes being only du

Re: [PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5

2015-02-18 Thread Andrey Andreev
Hi, On Wed, Feb 18, 2015 at 11:23 PM, Leigh wrote: > I would like a way of enabling strict by > default, immutable to scripts so that users cannot be forced into this > mode, and lets the radicals and the weaklings* play together in > harmony. > > For the rest of the RFC, I either agree with or h

Re: [PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5

2015-02-18 Thread Anthony Ferrara
Leigh, >> Internal Functions Like ceil() Return Unexpected Types > > My opinion is that functions should return sane types for their > intended purpose, and functions that do not should be "fixed". I agree 100%. I just think that's outside the scope of this proposal. >> Static Analysis Is Possib

Re: [PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5

2015-02-18 Thread Leigh
On 18 February 2015 at 21:50, Anthony Ferrara wrote: >>> Static Analysis Is Possible With Weak Declarations >> >> The advocacy of allowing `accepts_float(returns_int());` doesn't help >> the cause of static analysers in strict mode. > > Java does exactly this and is statically analyzable. So...?

Re: [PHP-DEV] Annotations in PHP7

2015-02-18 Thread Crypto Compress
Hi List, this may be off-topic. However i'm wondering how this could be an annotation? It looks like code. Why not include this into proper method? What am i missing? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Scalar Type Hints v0.4

2015-02-18 Thread Patrick ALLAERT
Le Wed Feb 18 2015 at 18:35:02, François Laupretre a écrit : > > De : Patrick ALLAERT [mailto:patrickalla...@php.net] > > ini_set("coercion_reporting", COERCION_ERROR); // Fail in case of > > potentially bad coercion > > > > foo(7); > > // int(7) > > foo("7"); > > // int(7) >

Re: [PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5

2015-02-18 Thread Albert Casademont Filella
Hi Anthony! Thanks for bringing this up again. I am asking you the same I asked Andrea 2 weeks ago on Twitter: make it a triple option vote please. She didn't want to do it, hope you do! This way you eliminate the neverending discussion about weak vs strict, let the votes decide and see who really

  1   2   >