Le Thu Feb 19 2015 at 00:38:25, François Laupretre franc...@php.net a
écrit :
This is definitely not the same case as generating a notice on array to
string (and why did you generate a notice instead of E_DEPRECATE, we would
be rid of this crap now).
I haven't decided that without discussing
Rowan Collins wrote in message news:54e4fac2.7060...@gmail.com...
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
Morning internals,
The expectations RFC is now in voting phase:
https://wiki.php.net/rfc/expectations#vote
Cheers
Joe
-Original Message-
From: Larry Garfield [mailto:la...@garfieldtech.com]
Sent: Thursday, February 19, 2015 9:00 AM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Reviving scalar type hints
On 02/17/2015 01:30 PM, Zeev Suraski wrote:
Yes, I already know that.
At this point, if
Nikita Nefedov wrote in message
news:CALuY8tjUq70eLkV-MbDi-fEXZvWTFi82zCNmWr7tmvpiES9=p...@mail.gmail.com...
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
On 19 בפבר׳ 2015, at 22:08, Anthony Ferrara ircmax...@gmail.com wrote:
Zeev,
Based on Sara's clarification in this thread, I owe you a formal
apology. I interpreted something she said incorrectly, which was then
compounded by messages in private and on-list this morning. I then
attributed
There isn't legitimate technical justification for or against using custom
exceptions.
Since it's entirely based on preference, and the kind of utilitarian
argument you can make for their use,
it's acceptable that this is resolved as part of the vote.
It's not a huge deal.
Cheers
Joe
On Thu,
Nikita (and all),
* Subclassing: Should there be more specific subclasses of EngineException
for particular errors?
I think there's an important case to be made here. I don't think every
error belongs having its own subclass, but there are at least a few
cases where it may make sense. This
On 19/02/15 18:16, Pierre Joye wrote:
This is not the point of this discussion. What you referto has to be
done for anything PHP uses, every library, every extension or services
(http or other).
Now read the rest of what I wrote ...
Where ever validated data comes from ... it does not need a
Zeev,
Based on Sara's clarification in this thread, I owe you a formal
apology. I interpreted something she said incorrectly, which was then
compounded by messages in private and on-list this morning. I then
attributed both of you qualities and motives that have been proven
false.
For this, I am
Hi!
So rather than go for the 70-75% consensus that we **know** we have,
How we magically know that? We have the (unfinished) vote, which has a
tiny bit over 66% for the proposal. Where 75% comes from?
I created a forked RFC. You can keep her as lead all you want, that
doesn't mean I can't
Stas,
I created a forked RFC. You can keep her as lead all you want, that
doesn't mean I can't move forward with my RFC.
I think it would really be better to have a lot less us vs them and a
bit more cooperative spirit here.
That ignores the mail that spawned this thread (and the one I got
On Wed, Feb 18, 2015 at 10:30 PM, Dan Ackroyd dan...@basereality.com
wrote:
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
On 19/02/15 01:33, Christoph Becker wrote:
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,
On 19/02/15 04:44, Dennis Birkholz wrote:
I just saw the reddit where you mention that v0.4 is practically
abandoned now, so I will just renounce my previous mail!
DO NOT USE OTHER CHANNELS!
With the large number of secondary channels the only place that
suggestions like that should be made is
On 19 Feb 2015, at 12:54, Dmitry Stogov dmi...@zend.com wrote:
I think we may introduce the following hierarchy
abstarct class BaseException {
}
class Exception extends BaseException {
}
class EngineException extends BaseException {
}
the existing code that caught Exception is
On Thu, Feb 19, 2015 at 12:03 PM, Tony Marston tonymars...@hotmail.com
wrote:
Rowan Collins wrote in message news:54e4fac2.7060...@gmail.com...
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
On 19/02/15 09:13, Zeev Suraski wrote:
Obviously, I think 'weak' campers have a lot to gain too - by making
sensible conversions work fine as expected, without having to resort to
explicit casts.
And everyone stands to gain from having just one mode, instead of two.
The coercive typing
De : Lester Caine [mailto:les...@lsces.co.uk]
On 19/02/15 04:44, Dennis Birkholz wrote:
I just saw the reddit where you mention that v0.4 is practically
abandoned now, so I will just renounce my previous mail!
DO NOT USE OTHER CHANNELS!
Agreed.
And the RFC was not abandoned at all. I
Le Thu Feb 19 2015 at 00:38:25, François Laupretre franc...@php.net a
écrit :
Why can't strictness follow that path?
Because strictness is not the overall objective the PHP language is aiming
to.
I cannot agree more with that.
If it was the case, your mechanism would be fine, but
Hi Patrick,
We already plan a similar mechanism by raising an E_DEPRECATED on conversions
that would have succeded in PHP 5 and will fail using the proposed new ‘PHP 7’
ZPP ruleset.
Then, it is technically possible to raise a notice on non-strict conversion but
it must be discussed in
Dennis,
Will you consider to let the people vote on how to enable strict mode
like discussed in the v0.4 discussion? Like this here from the Reviving
scalar type hints thread?
I believe that RFCs should be opinionated. I dislike the recent trend
around having a lot of voting options as it
On 19/02/15 13:16, Nikita Nefedov wrote:
Why not space? It's certainly possible (I just checked) and it would look
clear I guess:
my_func(1 999 999);
Yes, but what if I just missed one or two commas there? ;)
--
Regards,
Mike
--
PHP Internals - PHP Runtime Development Mailing
Hi,
I drafted an RFC to continue output buffering despite an aborted
connection was detected. The title might well be a bit misleading, so
please read the RFC before judgement.
https://wiki.php.net/rfc/continue_ob
--
Regards,
Mike
--
PHP Internals - PHP Runtime Development Mailing List
To
Zeev,
On Thu, Feb 19, 2015 at 8:52 AM, Zeev Suraski z...@zend.com wrote:
-Original Message-
From: Anthony Ferrara [mailto:ircmax...@gmail.com]
Sent: Thursday, February 19, 2015 3:24 PM
To: franc...@php.net
Cc: Lester Caine; internals@lists.php.net
Subject: [PHP-DEV] Using Other
2015-02-19 6:44 GMT+04:00 Rasmus Lerdorf ras...@lerdorf.com:
I think it will be difficult to find a separator character that doesn't
make a mess of the grammar.
my_func(1,999,999) obviously doesn't work
my_func(1'999'999) as per C++14 clashes with our single-quoted strings
Hi Lester,
I didn't add restrictions specific to number representation in the draft
ruleset yet, becausen while I think that's an important point, I didn't have
time to study it in depth.
I know you're an expert on this as you continuously (rightly) raised the point.
So, can you elaborate on
Le Wed Feb 18 2015 at 19:10:08, François Laupretre franc...@php.net a
écrit :
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
Francois and Lester (and all),
Please keep this thread on-topic. It should be for technical
discussions around this RFC only. If you have something non-technical
to discuss, please start a new topic.
Thanks
Anthony
On Thu, Feb 19, 2015 at 6:58 AM, François Laupretre franc...@php.net wrote:
De
-Original Message-
From: Lester Caine [mailto:les...@lsces.co.uk]
Sent: Thursday, February 19, 2015 12:24 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Reviving scalar type hints
On 19/02/15 09:13, Zeev Suraski wrote:
Obviously, I think 'weak' campers have a lot to gain
Hello Anthony,
Am 19.02.2015 um 14:01 schrieb Anthony Ferrara:
I believe that RFCs should be opinionated. I dislike the recent trend
around having a lot of voting options as it only complicates things
for the voter.
I just thought giving a vote on how to enable strict mode would enable a
few
Rasmus Lerdorf wrote:
On 02/18/2015 11:21 PM, Rick Widmer wrote:
how about:
my_func( '1,000.04' ); //if you want to use separators there.
The problem with that is that the world is split. The other half, or
actually more than half, would write that as '1.000,04'. There is no way
we
Francois
On Thu, Feb 19, 2015 at 6:58 AM, François Laupretre franc...@php.net wrote:
De : Lester Caine [mailto:les...@lsces.co.uk]
On 19/02/15 04:44, Dennis Birkholz wrote:
I just saw the reddit where you mention that v0.4 is practically
abandoned now, so I will just renounce my previous
2015-02-19 12:26 GMT+01:00 François Laupretre franc...@php.net:
Hi Patrick,
I know you didn’t decide it alone, but the right solution, IMO, would have
been to E_DEPRECATE nonsense conversions. That’s what we are currently doing
for ZPP conversions
-Original Message-
From: Anthony Ferrara [mailto:ircmax...@gmail.com]
Sent: Thursday, February 19, 2015 3:24 PM
To: franc...@php.net
Cc: Lester Caine; internals@lists.php.net
Subject: [PHP-DEV] Using Other Channels (was Scalar Type Declarations
v0.5)
Let me quote something that
On Thu, Feb 19, 2015 at 5:52 AM, Zeev Suraski z...@zend.com wrote:
-Original Message-
From: Anthony Ferrara [mailto:ircmax...@gmail.com]
Sent: Thursday, February 19, 2015 3:24 PM
To: franc...@php.net
Cc: Lester Caine; internals@lists.php.net
Subject: [PHP-DEV] Using Other Channels
On 02/18/2015 11:49 PM, Michael Wallner wrote:
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
Hi Joe,
I think, we may just add additional vote question.
- If we like to custom exceptons as second argument?
but I don't care about it, so do as you like.
According to AssertException: add a note into Open Issues section.
e.g. we may introduce new abstract class BaseException
then make
On Thu, Feb 19, 2015 at 12:50 AM, Anthony Ferrara ircmax...@gmail.com
wrote:
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
I think that structure makes sense Dmitry.
Though, just a bit on naming here (I know, its not a big deal, and naming
is hard, haha):
I think that naming the new parent exception something like Throwable or
Catchable (as Nikita previously suggested) would be a bit more concise in
meaning than
2015-02-19 17:14 GMT+02:00 Pierre Joye pierre@gmail.com:
On Thu, Feb 19, 2015 at 7:11 AM, Arvids Godjuks
arvids.godj...@gmail.com wrote:
I think this starts to go the route of putting things into absolute.
Ideal
things tend not to happen/work in the real world to the letter.
Some
On Thu, Feb 19, 2015 at 6:14 PM, Trevor Suarez ric...@gmail.com wrote:
I think that structure makes sense Dmitry.
Though, just a bit on naming here (I know, its not a big deal, and naming
is hard, haha):
I think that naming the new parent exception something like Throwable or
Catchable (as
On Thu, Feb 19, 2015 at 5:47 PM, Markus Fischer mar...@fischer.name wrote:
Hi,
On 19.02.15 10:09, Joe Watkins wrote:
Morning internals,
The expectations RFC is now in voting phase:
https://wiki.php.net/rfc/expectations#vote
- I somehow miss information what the exact differences
On Thu, Feb 19, 2015 at 7:16 AM, Dmitry Stogov dmi...@zend.com wrote:
On Thu, Feb 19, 2015 at 6:00 PM, Pierre Joye pierre@gmail.com wrote:
On Thu, Feb 19, 2015 at 1:09 AM, Joe Watkins pthre...@pthreads.org
wrote:
Morning internals,
The expectations RFC is now in voting phase:
-Original Message-
From: Pierre Joye [mailto:pierre@gmail.com]
Sent: Thursday, February 19, 2015 4:52 PM
To: Zeev Suraski
Cc: PHP internals
Subject: Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations
v0.5)
On Thu, Feb 19, 2015 at 6:33 AM, Zeev Suraski
On Thu, Feb 19, 2015 at 7:11 AM, Arvids Godjuks
arvids.godj...@gmail.com wrote:
I think this starts to go the route of putting things into absolute. Ideal
things tend not to happen/work in the real world to the letter.
Some things just don't work out by themselves. The Type Hinting RFC's are
One question just popped up in my mind: what happens if there is a global
error handler in place that rethrows errors as exceptions. I heard such a
thing suggested pretty often. If not parse errors and other engine errors
get thrown as exceptions and are unhandled as such, and that error handler
On 19 February 2015 at 09:54, Dmitry Stogov dmi...@zend.com wrote:
I think we may introduce the following hierarchy
the existing code that caught Exception is going to be unaffected.
We could do that. But it's not obviously correct, and ought to be
justified as to why it would be the correct
Hello!
The PHP development team announces the immediate availability of PHP
5.4.38. Seven security-related bugs were fixed in this release,
including CVE-2015-0273 and mitigation for CVE-2015-0235. All PHP 5.4
users are encouraged to upgrade to this version.
For source downloads of PHP 5.4.38
On Thu, Feb 19, 2015 at 7:21 AM, Zeev Suraski z...@zend.com wrote:
-Original Message-
From: Pierre Joye [mailto:pierre@gmail.com]
Sent: Thursday, February 19, 2015 4:52 PM
To: Zeev Suraski
Cc: PHP internals
Subject: Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations
Exception declares protected properties that may be used in child classes
directly.
This is not possible with interface.
Thanks. Dmitry.
On Thu, Feb 19, 2015 at 6:31 PM, Dan Ackroyd dan...@basereality.com wrote:
On 19 February 2015 at 09:54, Dmitry Stogov dmi...@zend.com wrote:
I think we
2015-02-19 17:41 GMT+02:00 Anthony Ferrara ircmax...@gmail.com:
Arvids,
I meant it in a way that no other RFC has failed so many times or had so
much misunderstanding or divide.
No scalar type proposal has made it through a vote. So none of them
have technically failed (all except the
Zeev,
Then that's great! But let's find that out by voting rather than guessing,
and
rather than politicking. Let's let two competing proposals go head to
head.
I'd rather find out by first discussing the alternative, rather than just
moving ahead to a revote - especially a revote that was
On Thu, Feb 19, 2015 at 10:02 AM, Lester Caine les...@lsces.co.uk wrote:
While typing this I did think to just scrap what I was writing, but I
think it is relevant if only if someone can explain why I am wrong?
On 19/02/15 17:06, Anthony Ferrara wrote:
With strictly typed $a and $b, the
Nikita Nefedov wrote:
2015-02-19 6:44 GMT+04:00 Rasmus Lerdorf ras...@lerdorf.com:
I think it will be difficult to find a separator character that doesn't
make a mess of the grammar.
Why not space? It's certainly possible (I just checked) and it would look
clear I guess:
my_func(1
Hi folks :)
I know everyone is already quite busy attempting to resolve scalar
types, assertions, etc. So let me add another RFC to your
pre-feature-freeze cognitive overload! This proposal allows the
specification of and access to Generator return expressions:
Hi all,
Those of you with long memories will remember that I proposed a
Comparable interface way back in the pre-5.4 days, but withdrew it
when it became obvious that there was no consensus for it as a feature
and that a vote was likely to fail.
RFC: https://wiki.php.net/rfc/comparable
PR:
On Thu, Feb 19, 2015 at 11:26 PM, Anthony Ferrara ircmax...@gmail.com
wrote:
Nikita (and all),
* Subclassing: Should there be more specific subclasses of
EngineException
for particular errors?
I think there's an important case to be made here. I don't think every
error belongs having
Those of you with long memories will remember that I proposed a
Comparable interface way back in the pre-5.4 days, but withdrew it
when it became obvious that there was no consensus for it as a feature
and that a vote was likely to fail.
RFC: https://wiki.php.net/rfc/comparable
PR:
I don't want to get into a lengthy debate (you have your opinion; I
have mine!), but to rebut a couple of specific points:
On 19 February 2015 at 14:19, Levi Morrison le...@php.net wrote:
Another issue: it allows comparing an object to non-objects (even
though the stated goal is only to compare
But even here I would rather just take a function instead of requiring
it to be the instance of some interface:
function sort($input, callable $comparator($a, $b): int) {
/* … */
}
Fair, but the sorting case isn't the only one that matters,
particularly with = now as part of the
On 02/19/2015 04:13 AM, Zeev Suraski wrote:
-Original Message-
From: Larry Garfield [mailto:la...@garfieldtech.com]
Sent: Thursday, February 19, 2015 9:00 AM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Reviving scalar type hints
On 02/17/2015 01:30 PM, Zeev Suraski wrote:
Yes, I
Hi Levi,
Just my opinion :
Add 'resource', 'object', 'scalar', 'mixed', 'numeric'
Remove 'double' (avoid this alias if we decide to encourage 'float' everywhere)
Not sure we'll use Boolean and integer but reserve also.
Hope 'null', 'true', and 'false' can technically be used as type hints. If
On Thu, Feb 19, 2015 at 5:36 PM, Levi Morrison le...@php.net wrote:
I would like to discuss a small RFC for reserving more types in PHP 7:
https://wiki.php.net/rfc/reserve_more_types_in_php_7
Essentially it proposes to reserve:
int, integer
bool, boolean
true, false
float, double
string
2015-02-12 20:55 GMT-03:00 Stelian Mocanita steli...@php.net:
I could compromise to send pull requests and update some of these tools
(at
least the open source ones) in time for PHP7 release.
Print screen taken, will hold you to your words.
Please do ;) If the RFC passes I'll be happy
On Thu, Feb 19, 2015 at 6:13 PM, François Laupretre franc...@php.net wrote:
De : Pádraic Brady [mailto:padraic.br...@gmail.com]
As I understand it, Andrea left her RFC free to be reused, reopened
and derived without any specific limitation. It would therefore appear
that it would be possible
Hello!
The PHP development team announces the immediate availability of PHP 5.6.6.
This release fixes several bugs and addresses CVE-2015-0235 and
CVE-2015-0273.
All PHP 5.6 users are encouraged to upgrade to this version.
For source downloads of PHP 5.6.6 please visit our
downloads page:
On Thu, Feb 19, 2015 at 1:40 PM, Adam Harvey ahar...@php.net wrote:
Hi all,
Those of you with long memories will remember that I proposed a
Comparable interface way back in the pre-5.4 days, but withdrew it
when it became obvious that there was no consensus for it as a feature
and that a
De : Pierre Joye [mailto:pierre@gmail.com]
Such as? Competition is good and my past experiences is that in cases
like this one, it is nearly an utopia to think that the other party
will actually try to reach your needs. So the only way to actually get
a RFC representing what you want to
Bishop,
Pardon me for saying so, but I don't think you're on to a huge scoop here.
Scalar type hints - of all the kinds we've been talking about here, be them
strict, weak or coercive - can be easily emulated with a couple of lines of
code, we all know that. It's been known for years that strict
On Fri, Feb 20, 2015 at 4:57 AM, Anthony Ferrara ircmax...@gmail.com
wrote:
Larry,
Anthony, can you expand here at all about the practical benefits of
strong-typing for variable passing for the compiler? That seems to be
the
main point of contention: Whether or not there are real,
Hi internals,
I'd like to put the Context Sensitive Lexer RFC into discussion phase:
RFC: https://wiki.php.net/rfc/context_sensitive_lexer
TL;DR commit: https://github.com/marcioAlmada/php-src/commit/c01014f9
PR: https://github.com/php/php-src/pull/1054
PHP currently has ~64 globally reserved
Hi Ferenc,
Ferenc Kovacs tyr...@php.net writes:
Hello!
The PHP development team announces the immediate availability of PHP 5.6.6.
This release fixes several bugs and addresses CVE-2015-0235 and
CVE-2015-0273.
All PHP 5.6 users are encouraged to upgrade to this version.
For source
2015-02-20 2:36 GMT+01:00 Levi Morrison le...@php.net:
int, integer
bool, boolean
true, false
float, double
I guess we should add 'real' here as well, since we still have the
(real) type cast and is_() type check for consistency:
C:\dev\php-srcphp -r var_dump((real) 42, is_real(13.37));
Hi Bishop,
On Wed, Feb 18, 2015 at 9:18 PM, Bishop Bettini bis...@php.net wrote:
THING 2: Hints are truthy callables
function my_mixed($m) {
return (null === $m || is_string($m));
}
function f(is_scalar $s, is_int $i, my_mixed $m) {};
This is interesting idea. I'm sure it will be
Hi all,
On Fri, Feb 20, 2015 at 12:14 AM, Trevor Suarez ric...@gmail.com wrote:
I think that naming the new parent exception something like Throwable or
Catchable (as Nikita previously suggested) would be a bit more concise in
meaning than BaseException. You may not have even meant that name
I'm not sure. Currently we don't use namespaces for core classes, but I
won't object to change this.
Nikita, what do you think?
Thanks. Dmitry.
On Fri, Feb 20, 2015 at 10:01 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi all,
On Fri, Feb 20, 2015 at 12:14 AM, Trevor Suarez ric...@gmail.com
Dear Internals,
I would like to discuss a small RFC for reserving more types in PHP 7:
https://wiki.php.net/rfc/reserve_more_types_in_php_7
Essentially it proposes to reserve:
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sorry: Apparently hit some hotkey for send.
On Thu, Feb 19, 2015 at 6:35 PM, Levi Morrison le...@php.net wrote:
Dear Internals,
I would like to discuss a small RFC for reserving more types in PHP 7:
https://wiki.php.net/rfc/reserve_more_types_in_php_7
Essentially it proposes to reserve:
Stas,
On Thu, Feb 19, 2015 at 9:32 AM, Stanislav Malyshev smalys...@gmail.com wrote:
Hi!
So rather than go for the 70-75% consensus that we **know** we have,
How we magically know that? We have the (unfinished) vote, which has a
tiny bit over 66% for the proposal. Where 75% comes from?
Hey Anthony,
-Ursprüngliche Nachricht-
Von: Anthony Ferrara [mailto:ircmax...@gmail.com]
Gesendet: Mittwoch, 18. Februar 2015 21:45
An: internals@lists.php.net
Betreff: [PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5
Dear Internals,
Since the resignation of Andrea, the
On Thu, Feb 19, 2015 at 8:21 AM, Lester Caine les...@lsces.co.uk wrote:
On 19/02/15 12:52, Zeev Suraski wrote:
Now that all made sense!
My only grey area is 'allowing sensible ones' where the size is an
integral part
of what is 'sensible' ... the one where conventional strict typing uses
On Thu, Feb 19, 2015 at 7:06 PM, Dan Ackroyd dan...@basereality.com wrote:
On 19 February 2015 at 15:46, Dmitry Stogov dmi...@zend.com wrote:
Exception declares protected properties that may be used in child classes
directly.
This is not possible with interface.
So, you're saying it's
I am not familiar with the implementation details but from my perspective
this would be a nice improvement. I have had a difficult time debugging PHP
fatal errors over the years and I think this kind of change would help
improve that.
On Mon, Oct 6, 2014 at 4:53 PM, Nikita Popov
On 19 February 2015 at 16:25, Dmitry Stogov dmi...@zend.com wrote:
we are tying to
do it with minimal breaks for our users. If we may keep compatibility, we
would prefer to keep it,
Yeah - you still haven't said why choosing to extend exception rather
than using an interface has fewer BC
On 19 February 2015 at 15:46, Dmitry Stogov dmi...@zend.com wrote:
Exception declares protected properties that may be used in child classes
directly.
This is not possible with interface.
So, you're saying it's easier to implement?
That isn't a fantastic way of making a language design
On 19/02/15 15:21, Zeev Suraski wrote:
Focusing on my email to Sara (and several others), there is NOTHING, nothing
wrong with a bit of private communications trying to gauge support,
opposition, gaps and sort out differences before going for a public
discussion.
My original comment was on
On Thu, Feb 19, 2015 at 7:45 AM, Pierre Joye pierre@gmail.com wrote:
On Thu, Feb 19, 2015 at 7:16 AM, Dmitry Stogov dmi...@zend.com wrote:
On Thu, Feb 19, 2015 at 6:00 PM, Pierre Joye pierre@gmail.com wrote:
On Thu, Feb 19, 2015 at 1:09 AM, Joe Watkins pthre...@pthreads.org
wrote:
On 19/02/15 12:52, Zeev Suraski wrote:
Now that all made sense!
My only grey area is 'allowing sensible ones' where the size is an
integral part
of what is 'sensible' ... the one where conventional strict typing uses a
type
of the right size?
I think the guiding principal for these
Arvids,
I meant it in a way that no other RFC has failed so many times or had so
much misunderstanding or divide.
No scalar type proposal has made it through a vote. So none of them
have technically failed (all except the current one were withdrawn).
Sometimes it is required to ditch the
Hi!
Based on the no reasons that people presented, and some back-of-envelope math.
That is not knowing, much less **knowing**. That is a guess based on
an estimate and set of assumptions, some of which very well may be wrong
(such as, people can have more than one reason to vote no).
The
On 19 February 2015 at 15:45, Pierre Joye pierre@gmail.com wrote:
Still, no announce for a discussion about this specific RFC. And
really, the content of the RFC is almost empty, pointing to the ML
archive is really not the right way :)
There was an RFC announce thread 3 days ago. I agree
On Thu, Feb 19, 2015 at 5:24 AM, Anthony Ferrara ircmax...@gmail.com wrote:
On Thu, Feb 19, 2015 at 6:58 AM, François Laupretre franc...@php.net wrote:
As long as she does not officially gives up (posting to the list), I'll keep
considering Sara still has the lead on scalar type hinting. If
Hi!
At the function border, yes. But not beyond that.
Not sure what you mean here. If the value is identified as int, it
remains int. How strict typing would change that?
Sort-of correct. We don't know if A is true, but we know what
conditions need to exist for A-B to be true. We know that A
-Original Message-
From: Anthony Ferrara [mailto:ircmax...@gmail.com]
Sent: Thursday, February 19, 2015 4:04 PM
To: Zeev Suraski
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations
v0.5)
Zeev,
That was a quote directly from Sara
Hi!
So rather than go for the 70-75% consensus that we **know** we have,
How we magically know that? We have the (unfinished) vote, which has a
tiny bit over 66% for the proposal. Where 75% comes from?
Saying a problem doesn't exist doesn't make it go away.
Except if it really doesn't exist,
-Original Message-
From: Anthony Ferrara [mailto:ircmax...@gmail.com]
Sent: Thursday, February 19, 2015 4:24 PM
To: Zeev Suraski
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations
v0.5)
Zeev,
This topic has been discussed to
On Thu, Feb 19, 2015 at 6:33 AM, Zeev Suraski z...@zend.com wrote:
-Original Message-
From: Pierre Joye [mailto:pierre@gmail.com]
Sent: Thursday, February 19, 2015 4:09 PM
To: Zeev Suraski
Cc: Anthony Ferrara; PHP internals
Subject: Re: [PHP-DEV] Using Other Channels (was Scalar
2015-02-19 16:51 GMT+02:00 Pierre Joye pierre@gmail.com:
On Thu, Feb 19, 2015 at 6:33 AM, Zeev Suraski z...@zend.com wrote:
-Original Message-
From: Pierre Joye [mailto:pierre@gmail.com]
Sent: Thursday, February 19, 2015 4:09 PM
To: Zeev Suraski
Cc: Anthony Ferrara; PHP
-Original Message-
From: Pierre Joye [mailto:pierre@gmail.com]
Sent: Thursday, February 19, 2015 4:09 PM
To: Zeev Suraski
Cc: Anthony Ferrara; PHP internals
Subject: Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations
v0.5)
We have seen off list discussions or
1 - 100 of 117 matches
Mail list logo
