Hi!
> Probability based GC is unreliable and can reactivate very old sessions
> without "Precise session management RFC" and you opposed the RFC.
You know why I opposed the RFC - because it had huge number of things
packed together, some of which I agree with, some of which I disagree
and some of
Hi,
On Mon, Apr 18, 2016 at 3:26 AM, Yasuo Ohgaki wrote:
>
> Probability based GC is unreliable and can reactivate very old sessions
> without "Precise session management RFC" and you opposed the RFC.
>
>
While I agree that calling session_gc() on a regular basis is the better
option, that doesn
On 18/04/16 04:56, Larry Garfield wrote:
> 2) Doesn't make it quite so easy, which hopefully discourages (but does
> not prohibit) its usage.
This implies that using 'null' is wrong ... and is a slippery slope to
then 'disabling' null where some people think it should be removed. If
PHP developmen
Hi,
On Sat, Apr 16, 2016 at 12:15 AM, Yasuo Ohgaki wrote:
> Hi Stas,
>
> On Wed, Apr 13, 2016 at 2:25 AM, Stanislav Malyshev
> wrote:
> >> Lack of proper API for required task is our problem. Misuse is not
> ours. IMHO.
> >
> > No, it is our problem. We can't just create whatever and throw it o
wrote in message news:57135893.3070...@fleshgrinder.com...
On 4/17/2016 11:19 AM, Tony Marston wrote:
Where is the insult in what I wrote?
You are not only insulting people in this thread, you do it in every
thread you contribute to. You were exhorted multiple times for doing so.
Pretending
The grammar is taken from HHVM.
Using any other would make more mess.
Thanks. Dmitry.
From: Tom Worster
Sent: Saturday, April 16, 2016 04:54
To: Dmitry Stogov; internals
Subject: Re: [PHP-DEV] [RFC] Nullable Types
On 4/15/16 1:58 PM, Dmitry Stogov wrote:
On 04/15/2016 11:07 PM, Stanislav Malyshev wrote:
Hi!
In most cases we avoid IS_UNDEF checks, verifying the most probable expected
types first.
But that's for something like ADD, not for property fetches, so I'm not
sure I understand how properties fit there yet. Does the optimization
also
On Mon, Apr 18, 2016 at 6:20 AM, Rasmus Schultz wrote:
> Hello internals,
>
> I'd like to introduce an RFC proposing the addition of generic types
> and functions:
>
> https://wiki.php.net/rfc/generics
>
> Ben Scholzen started this RFC as a quick draft with a few code samples
> in August last year
Morning Internals,
Please review the following RFC:
https://wiki.php.net/rfc/functional-interfaces
An implementation is provided, and is testable on 3v4l.
Review of the implementation from those of you that do that would be
good :)
Cheers
Joe
On Mon, Apr 18, 2016 at 10:47 AM, Josh Di Fabio wrote:
> On Mon, Apr 18, 2016 at 6:20 AM, Rasmus Schultz wrote:
>> Hello internals,
>>
>> I'd like to introduce an RFC proposing the addition of generic types
>> and functions:
>>
>> https://wiki.php.net/rfc/generics
>>
>> Ben Scholzen started this
Hi,
by accident a developer pushed master onto the PHP-7.0 branch. A force
push was used to repair the repository.
The broken state has been backed up here:
https://github.com/johannes/php-src/tree/backup-broken-7.0
From there the revision has been reverted to 8f35ee49ee.
If you pulled within t
Joe Watkins wrote on 18/04/2016 11:22:
Please review the following RFC:
https://wiki.php.net/rfc/functional-interfaces
An implementation is provided, and is testable on 3v4l.
This sounds like a really nice feature. As well as using functions to
implement existing interfaces, i
Results for project PHP master, build date 2016-04-18 06:35:14+03:00
commit: 60b1441
previous commit:a186ac0
revision date: 2016-04-07 10:26:32+09:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
Morning,
> I must admit to being a bit confused by the term "functional
interface" at first, though,
> because "functional" has so many different meanings - is this a term
used elsewhere,
> or is it up for debate?
The terminology is borrowed, Java 8 uses lamdas to implement specially
Joe Watkins wrote on 18/04/2016 12:53:
Morning,
> I must admit to being a bit confused by the term "functional
interface" at first, though,
> because "functional" has so many different meanings - is this a
term used elsewhere,
> or is it up for debate?
The terminology is borrowed
Heya,
I voted "NO" due to previous discussion. TL;DR: this is FAR off the 80/20
use-case for a language syntax change.
C&P from my answer elsewhere:
The following typical example is something REALLY rare, and requiring a
parser change for it seems excessive:
try {
// ...
} catch
> -Original Message-
> From: Marco Pivetta [mailto:ocram...@gmail.com]
> Sent: Monday, April 18, 2016 4:41 PM
> To: Dan Ackroyd
> Cc: Bronisław Białek ; PHP internals
>
> Subject: Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types
>
> Heya,
>
> I voted "NO" due to previous discuss
You missed what I said.
You can do multiple single class/function/constant in a single statement,
but you cannot do multiple group use in a single statement. This:
use Foo\Bar,
Foo\Baz\{Qux, Corge};
Regards,
On Fri, Apr 15, 2016 at 9:38 PM, Lin Yo-An wrote:
> I thought there was one alread
On Mon, 18 Apr 2016, Marco Pivetta wrote:
> Heya,
>
> I voted "NO" due to previous discussion. TL;DR: this is FAR off the 80/20
> use-case for a language syntax change.
I'm with you on this one.
> C&P from my answer elsewhere:
>
> The following typical example is something REALLY rare, and req
On Mon, Apr 18, 2016 at 4:59 PM, Dmitry Stogov wrote:
> The grammar is taken from HHVM.
> Using any other would make more mess.
>
I agree
On 4/18/16 3:00 AM, Lester Caine wrote:
On 18/04/16 04:56, Larry Garfield wrote:
2) Doesn't make it quite so easy, which hopefully discourages (but does
not prohibit) its usage.
This implies that using 'null' is wrong ... and is a slippery slope to
then 'disabling' null where some people think
On 18 April 2016 at 16:17, Derick Rethans wrote:
> If they are user defined exceptions, you should make them implement an
> interface,
Even within one oranisation, getting different teams to agree to
common interfaces is not always possible. But when the exceptions are
originating in code that p
On 18/04/16 17:57, Larry Garfield wrote:
> On 4/18/16 3:00 AM, Lester Caine wrote:
>> On 18/04/16 04:56, Larry Garfield wrote:
>>> 2) Doesn't make it quite so easy, which hopefully discourages (but does
>>> not prohibit) its usage.
>> This implies that using 'null' is wrong ... and is a slippery sl
Hi!
> I am not sure what you're implying by "some people have no appreciation
> of the usefulness of"... I am well aware of NULL's use cases. I am also
> well aware that the general zeitgeist in the language development
> community is that they're dangerous; the designer of the first language
I
+1 for the feature, very nice syntactic sugar to solve some edge cases.
I agree with Rowan, i also do not like the name and propose to call them
*closure interfaces*. There are already various synonyms for closures:
- anonymous function
- lambda function
- callback*
However, the strongest argume
Hi!
> right.
> I don't see any reasons for types, if they are not guaranteed anyway.
Well, we already have parameter types, and they are not guaranteed
either - you can reassign variables.
> This depends on use case.
> Just imagine matrix multiplication (or something similar).
> Few additional i
On 4/18/2016 8:24 PM, Stanislav Malyshev wrote:
>> to have them calls them a "billion dollar mistake", many languages
>> actively avoid having NULL in favor of something deliberately more
>> structured. NULLs are a very common cause of avoidable fatal errors in
>> many languages (including PHP). N
On 18/04/16 19:24, Stanislav Malyshev wrote:
> If your database died, your DB-bound code is not going
> to fix it. With or without nulls - it has to just fail and wait for
> somebody to fix it. There's no need to overcomplicate that.
If the DB read failed due to the connection being lost, then tha
Hi!
>> Document calling session_gc() periodically is the best practice.
>
> If you want to document usage of this new API as the best practice, it
> would be unfair to the users if you don't also document the caveats that
> come with it:
I also think it's wrong to document it so. While having pe
On 4/18/2016 7:22 AM, Marcio Almada wrote:
> 2016-04-17 23:56 GMT-04:00 Larry Garfield :
>> Rather than debate the relative merits of Null as a concept, since I think
>> all agree removing Null from the language is not even a thing, what do you
>> think of my recommendation to NOT have the ? shorth
Hi,
Le 13/04/2016 17:55, Lin Yo-An a écrit :
Hi internals,
The javascript engine V8 uses a strategy called "startup snapshot" to
optimize app load time (see
http://v8project.blogspot.tw/2015/09/custom-startup-snapshots.html for more
details)
The approach used by V8 creates a snapshot from hea
Hi!
> Please review the following RFC:
>
> https://wiki.php.net/rfc/functional-interfaces
>
> An implementation is provided, and is testable on 3v4l.
This looks like a rather narrow case already covered by anonymous
classes. Am I missing something? What is the added value of it that
Hi!
> Even this is a scary way to do it. As you don't know which exception
> class you have, how would you know how to handle each separately. You'd
> have to if ($caught instanceof InvalidArgumentException) etc to be sure
> that what you're doing with the object is allowed.
I just recently ha
Hi!
2016-04-18 15:17 GMT-04:00 Stanislav Malyshev :
> Hi!
>
> > Please review the following RFC:
> >
> > https://wiki.php.net/rfc/functional-interfaces
> >
> > An implementation is provided, and is testable on 3v4l.
>
> This looks like a rather narrow case already covered by anonymous
On 18/04/16 20:08, Fleshgrinder wrote:
> This is however a useful shortcut and shortcuts are good things in
> terms of usability if done write. Think of + vs. right click
>> > copy (or any other example of useful keyboard shortcuts).
Except when some sod adds a or decides left click is quicker
On Tue, Apr 12, 2016 at 7:38 PM, Sara Golemon wrote:
> https://wiki.php.net/rfc/octal.overload-checking
> Because having this expression evaluate to true makes me sad: ("\000"
> === "\400")
>
I haven't heard any responses on this and wanted to bump it back to
the top of your newsreaders.
For the
On Mon, Apr 18, 2016 at 12:17 PM, Stanislav Malyshev
wrote:
> Hi!
>
>> Please review the following RFC:
>> https://wiki.php.net/rfc/functional-interfaces
>> An implementation is provided, and is testable on 3v4l.
>
> This looks like a rather narrow case already covered by anonymous
> c
On Mon, Apr 18, 2016 at 9:40 AM, Marco Pivetta wrote:
>
> I voted "NO" due to previous discussion. TL;DR: this is FAR off the 80/20
> use-case for a language syntax change.
>
> ...
> These 3 exceptions usually result in separate handling anyway. If same
> handling is needed, you can as usual extr
Hi!
> catch constitutes a formal signature, exactly like a function signature. In
> my mind, this proposal and the union types proposal are intrinsically tied.
> If we have one, we must have the other. If not, we're inducing a sadness.
This has nothing to do with union types. It is just a shortcu
I just wanted to personally thank Sara Golemon, and the PHP internals team,
for being so incredibly approachable, open, and all-around awesome.
The fact that a simple, informal tweet can turn into a core feature is
incredible: https://twitter.com/trevorsuarez/status/709864419753377792
Thanks agai
On Mon, Apr 18, 2016 at 8:54 PM, Stanislav Malyshev
wrote:
> Hi!
>
> > catch constitutes a formal signature, exactly like a function signature.
> In
> > my mind, this proposal and the union types proposal are intrinsically
> tied.
> > If we have one, we must have the other. If not, we're inducing
Hi!
> It's about the perception of consistency. "Oh, I can do this! Neat:"
>
> function neat(Foo | Bar $a) { ... }
You shouldn't be able to do this, because it makes no sense - why would
a function accept two random types and only them? That's probably a bad
design - it should be one type or two
On 4/18/16 2:24 PM, Stanislav Malyshev wrote:
I would like to note in general that following the latest fashion in
academic development is not always a good idea for PHP. It's fine when
you experiment with academic languages, but when you have language that
a) focused on simplicity and low entra
On 4/18/16 4:34 AM, Tony Marston wrote:
I repeat, where was the insult in the post in question? What exactly
were the insulting words?
I chose just one example:
> Those who cannot write effective software without these "clever"
> additions to the language are doing nothing but announcing to
On 04/18/2016 08:28 PM, Stanislav Malyshev wrote:
Hi!
It's about the perception of consistency. "Oh, I can do this! Neat:"
function neat(Foo | Bar $a) { ... }
You shouldn't be able to do this, because it makes no sense - why would
a function accept two random types and only them? That's proba
Hi!
> Admittedly Foo|Bar is of limited use, although there is some use.
> Foo&Bar, however, has plenty of uses.
That is a different topic, not related to exceptions at all.
> I do agree with the sentiment that having Foo|Bar for catch but not for
> function signatures is going to confuse people.
46 matches
Mail list logo