Morning,
I hear the concern regarding custom exceptions. Things will be used badly
whatever. It's easy to imagine that in a simple application you just don't
need to specify custom exceptions. But in a large codebase, being able to
structure exceptions is invaluable, it gives documentation referen
On 19/02/15 03:44, Rasmus Lerdorf wrote:
> but _999_ would need to work as well and _ is a valid char in a constant
> so you can have a constant named _999_.
>
Why would we need to support the underscore in front (and maybe even at
the end) of a number?
--
Regards,
Mike
--
PHP Internals - P
On 02/18/2015 11:21 PM, Rick Widmer wrote:
> On 2/18/2015 7:44 PM, Rasmus Lerdorf wrote:
>> Now if we went into Unicode territory, we could do it. eg.
>>
>>my_func(1 999 999) U+1680 (although it looks too much like a -)
>>my_func(1 999 999) U+205F (mathematical space)
>>my_func(1٬999٬99
Hi!
> 2) PHP would benefit hugely from static analysis tools and compile-time
> type-based optimizations, but those are only possible with code that is
> strongly typed. Currently such tools do not really exist, but with
Is that really the case? Javascript has very good optimizing engine, and
Ja
On Thu, Feb 19, 2015 at 8:42 AM, Sara Golemon wrote:
> On Wed, Feb 18, 2015 at 11:22 AM, 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
On 2/18/2015 7:44 PM, Rasmus Lerdorf wrote:
On 02/18/2015 06:07 PM, Christoph Becker wrote:
Hi internals!
A while ago a question was asked on the php-general mailing list with
regard to digit seperators in numeric literals[1].
IMHO it might be a useful enhancement to allow such digit separator
On Thu, Feb 19, 2015 at 2:12 AM, François Laupretre
wrote:
> If I understand Dmitry correctly, this would be stored as the compiler
> internal representation of the 'new Entity("foo")' code, but this wouldn't
> be executed until an external mechanism decides to do so. So, this is PHP
> code and i
On 2/18/2015 6:33 PM, Christoph Becker wrote:
It seems to me you're thinking too much (maybe only?) about "database
types". IMHO PHP can be used more versatile, and there might be issues
which are exemplified in the RFC[1]:
Maybe PHP can be more versatile, but what percentage of PHP code sits
On 02/17/2015 01:30 PM, Zeev Suraski wrote:
Yes, I already know that.
The difference, and why I keep pointing that out, is that me and many
others
want strict typing for our own reasons (but still in its entirety instead
of as a
limited mode) and most of us don't even care if you getting weak typ
On 02/17/2015 12:48 AM, Sara Golemon wrote:
Don't mistake me for hack. -Sara
No one could ever mistake you for a hack, Sara. :-)
--Larry Garfield
(Sorry, it was just sitting there...)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 02/17/2015 01:15 AM, Kris Craig wrote:
To be clear: consensus is not leadership. Consensus cannot be
leadership. So the statement "leadership of the language is left to
consensus" is a very explicit and deliberate statement that the language
has no leadership.
On what basis are you making
On Wed, Feb 18, 2015 at 11:22 AM, 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
Am 19.02.2015 um 05:21 schrieb Dennis Birkholz:
> Am 18.02.2015 um 21:44 schrieb Anthony Ferrara:
>> 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 sever
Am 18.02.2015 um 21:44 schrieb Anthony Ferrara:
> 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 issu
On 02/18/2015 06:07 PM, Christoph Becker wrote:
> Hi internals!
>
> A while ago a question was asked on the php-general mailing list with
> regard to digit seperators in numeric literals[1].
>
> IMHO it might be a useful enhancement to allow such digit separators for
> numeric (integer and float)
Hi internals!
A while ago a question was asked on the php-general mailing list with
regard to digit seperators in numeric literals[1].
IMHO it might be a useful enhancement to allow such digit separators for
numeric (integer and float) literals in PHP for better readability;
several other languag
Lester Caine wrote:
> On 18/02/15 23:09, Christoph Becker wrote:
>> It seems to me that this behavior is hard to deal with generally for
>> programmers as well as static analyzers. Andreas' bigint RFC[1] would
>> solve that issue, but it has been withdrawn, and AFAIK nobody is working
>> on it.
Anthony,
Anthony Ferrara wrote:
> On Wed, Feb 18, 2015 at 6:09 PM, Christoph Becker wrote:
>
>> Have you considered the overflow behavior of ints resulting in a float?
>> For instance, the following code would produce E_RECOVERABLE_ERROR, AIUI:
>>
>> >
>> declare(strict_types=1);
>>
>> fu
On 18/02/15 23:09, Christoph Becker wrote:
> It seems to me that this behavior is hard to deal with generally for
> programmers as well as static analyzers. Andreas' bigint RFC[1] would
> solve that issue, but it has been withdrawn, and AFAIK nobody is working
> on it. OTOH, bigint would make the
> De : Patrick ALLAERT [mailto:patrickalla...@php.net]
> > My point is that it potentially imposes new warnings on foreign code.
>
> Eureka :)
>
> That's what happened when I introduced the "Array to string conversion":
> lot of people complained about it and many frameworks had to fix various
>
Christoph,
On Wed, Feb 18, 2015 at 6:09 PM, Christoph Becker wrote:
> Anthony Ferrara wrote:
>
>> 3. int typed variables can resolve a parameter type of float So
>> calling requiresAFloat(10) will work even in strict mode.
>
> Have you considered the overflow behavior of ints resulting in a floa
If I understand Dmitry correctly, this would be stored as the compiler internal
representation of the 'new Entity("foo")' code, but this wouldn't be executed
until an external mechanism decides to do so. So, this is PHP code and it is
compiled and stored in memory besides the function opcodes, b
Anthony Ferrara wrote:
> 3. int typed variables can resolve a parameter type of float So
> calling requiresAFloat(10) will work even in strict mode.
Have you considered the overflow behavior of ints resulting in a float?
For instance, the following code would produce E_RECOVERABLE_ERROR, AIUI:
On 18 February 2015 at 22:21, Albert Casademont Filella
wrote:
> So I propose 3 voting options: Yes (strict), Yes (weak), No. The Yes votes
> combined need 2/3 of the votes. Then a simple majority of 50%+1 between the
> different Yes votes is needed.
This is pretty flawed, but nice try.
--
PHP
Albert,
On Wed, Feb 18, 2015 at 5:21 PM, Albert Casademont Filella
wrote:
> 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
Le Wed Feb 18 2015 at 19:10:54, Sara Golemon a écrit :
> 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
> > c
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
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)
>
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
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...?
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
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
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
> 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
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
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
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
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 {
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
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
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
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
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.
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
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
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
> 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
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
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
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
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
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
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
> 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
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
> 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
> 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
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
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
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
> 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
> 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
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
> 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
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
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
> 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
> 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
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
> 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
> 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
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.
> 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
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
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
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
> -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
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
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
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
> -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
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));
>
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
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
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
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
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
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
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
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
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
> 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);
> }
>
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
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
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
>>
> -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
> 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
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
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
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
1 - 100 of 126 matches
Mail list logo
