On Wed, Feb 18, 2015 at 11:05 AM, Benjamin Eberlei kont...@beberlei.de
wrote:
On Wed, Feb 18, 2015 at 8:02 AM, Dmitry Stogov dmi...@zend.com wrote:
On Wed, Feb 18, 2015 at 12:51 AM, guilhermebla...@gmail.com
guilhermebla...@gmail.com wrote:
François,
Doctrine relies on nested
On Wed, Feb 18, 2015 at 8:02 AM, Dmitry Stogov dmi...@zend.com 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:
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 -
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 which are
On Wed, Feb 18, 2015 at 11:59 AM, Derick Rethans der...@php.net wrote:
On Tue, 17 Feb 2015, Dmitry Stogov wrote:
On Mon, Feb 16, 2015 at 10:57 PM, Derick Rethans der...@php.net wrote:
On Mon, 16 Feb 2015, Dmitry Stogov wrote:
hi,
During discussion of different ways of
Hi,
On Wed, Feb 18, 2015 at 9:00 AM, Zeev Suraski z...@zend.com 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
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
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 /all
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.
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
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
On 18 Feb 2015 13:53, Tony Marston tonymars...@hotmail.com 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
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 (we can add
On Tue, 17 Feb 2015, Dmitry Stogov wrote:
On Mon, Feb 16, 2015 at 10:57 PM, Derick Rethans der...@php.net 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.
Hi,
On Wed, Feb 18, 2015 at 11:54 AM, Lester Caine les...@lsces.co.uk 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
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 dmi...@zend.com wrote:
On
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
-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
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
On 18 בפבר׳ 2015, at 19:50, Rasmus Lerdorf ras...@lerdorf.com 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, Feb 18, 2015 at 7:34 AM, Patrick ALLAERT patrickalla...@php.net 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,
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 transforming 7 dogs to 7.
On Wed, Feb 18, 2015 at 5:44 PM, Nikita Popov nikita@gmail.com wrote:
On Tue, Feb 17, 2015 at 10:50 PM, Dmitry Stogov dmi...@zend.com 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
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
On Wed, Feb 18, 2015 at 6:14 PM, François Laupretre franc...@php.net
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
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 part is
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 than
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 was just
On Wed, 2015-02-18 at 16:17 +0100, Nikita Popov wrote:
On Wed, Feb 18, 2015 at 4:06 PM, Cesar Rodas ce...@rodas.me wrote:
On 18/02/15 15:59, Nikita Popov wrote:
On Wed, Feb 18, 2015 at 7:22 AM, Dmitry Stogov dmi...@zend.com wrote:
Hi,
On Tue, Feb 17, 2015 at 2:46 PM,
Hi Dmitry,
Are you (and Doctrine team) interested in this annotation idea?
I'd say that Benjamin nailed in our possible usage:
orm(new Entity(foo))
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
2015-02-18 22:22 GMT+03:00 Dmitry Stogov dmi...@zend.com:
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
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
On 13 February 2015 at 23:25, Nikita Popov nikita@gmail.com 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
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
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 of
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
On Wed, Feb 18, 2015 at 8:22 PM, Dmitry Stogov dmi...@zend.com 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
On Wed, Feb 18, 2015 at 7:28 PM, guilhermebla...@gmail.com
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:
orm(new Entity(foo))
class Foo {
}
Now I do feel we need to
Hi Guilherme,
De : guilhermebla...@gmail.com [mailto:guilhermebla...@gmail.com]
orm(
[
new OneToOne(Address),
new JoinColumn(default, default, default, default, CASCADE)
]
)
public $address;
Why not :
orm([
'OneToOne' = Address,
'JoinColumns' = [
On 18 February 2015 at 21:50, Anthony Ferrara ircmax...@gmail.com 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.
Hi,
On Wed, Feb 18, 2015 at 11:23 PM, Leigh lei...@gmail.com 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
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 Possible With
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 dmi...@zend.com:
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
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
On Wed, Feb 18, 2015 at 9:40 PM, François Laupretre franc...@php.net
wrote:
Hi Guilherme,
De : guilhermebla...@gmail.com [mailto:guilhermebla...@gmail.com]
orm(
[
new OneToOne(Address),
new JoinColumn(default, default, default, default, CASCADE)
]
)
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
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 $value =
On Wed, Feb 18, 2015 at 11:00 PM, Nikita Popov nikita@gmail.com wrote:
On Wed, Feb 18, 2015 at 8:22 PM, Dmitry Stogov dmi...@zend.com 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
On Wed, Feb 18, 2015 at 9:29 PM, Pavel Kouřil pajou...@gmail.com wrote:
On Wed, Feb 18, 2015 at 7:28 PM, guilhermebla...@gmail.com
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
Hi Tim,
Le Wed, 18 Feb 2015 10:44:20 +0100, Tim Bezhashvyly
tim.bezhashv...@gmail.com 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
On 18 February 2015 at 20:44, Anthony Ferrara ircmax...@gmail.com 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
Hi List,
orm(new Entity(foo))
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:
Le Wed Feb 18 2015 at 18:35:02, François Laupretre franc...@php.net 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)
Albert,
On Wed, Feb 18, 2015 at 5:21 PM, Albert Casademont Filella
albertcasadem...@gmail.com 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
Le Wed Feb 18 2015 at 19:10:54, Sara Golemon poll...@php.net a écrit :
On Wed, Feb 18, 2015 at 7:34 AM, Patrick ALLAERT patrickalla...@php.net
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
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
On Wed, Feb 18, 2015 at 11:22 AM, Dmitry Stogov dmi...@zend.com 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
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 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 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
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 issues
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: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
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 - PHP
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
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 several
On Thu, Feb 19, 2015 at 2:12 AM, François Laupretre franc...@php.net
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
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
On Thu, Feb 19, 2015 at 8:42 AM, Sara Golemon poll...@php.net wrote:
On Wed, Feb 18, 2015 at 11:22 AM, Dmitry Stogov dmi...@zend.com 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.
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٬999) U+066C
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
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, and
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 you
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
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++)
{
Hi,
On Wed, Feb 18, 2015 at 2:27 PM, François Laupretre franc...@php.net 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
On 18 February 2015 at 13:18, Rowan Collins rowan.coll...@gmail.com 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.
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);
}
function
Leigh wrote on 18/02/2015 13:31:
On 18 February 2015 at 13:18, Rowan Collins rowan.coll...@gmail.com 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
On Tue, Feb 17, 2015 at 10:50 PM, Dmitry Stogov dmi...@zend.com 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
On 18 February 2015 at 14:40, Lester Caine les...@lsces.co.uk 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
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 as octal
Hi all,
On 18 February 2015 at 09:14, Andrey Andreev n...@devilix.net wrote:
Hi,
On Wed, Feb 18, 2015 at 9:00 AM, Zeev Suraski z...@zend.com 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
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
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 as
-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-
Von:
De : Benjamin Eberlei [mailto:kont...@beberlei.de]
nested can be done in any way, its a statement so the following would work:
orm(new JoinTable(['joinColumns' = [new JoinColumn('id', 'other_id')]]))
Dmitry is planning compile time evaluation, which is probably the only way to
do it if we
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:
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 a strict
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 modifications
On 17 February 2015 at 22:03, Sara Golemon poll...@php.net 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,
Hi Zeev,
On Wed, Feb 18, 2015 at 2:31 PM, Zeev Suraski z...@zend.com 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
Hi François,
On Wed, Feb 18, 2015 at 3:02 PM, François Laupretre franc...@php.net 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
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
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 process.
Hi Sara (and thanks for continuing the work!)
Le Tue Feb 17 2015 at 23:04:20, Sara Golemon poll...@php.net 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
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 -
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
2015-02-18 12:45 GMT+01:00 Rowan Collins rowan.coll...@gmail.com:
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,
On Wed, Feb 18, 2015 at 7:22 AM, Dmitry Stogov dmi...@zend.com 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
1 - 100 of 120 matches
Mail list logo
