Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88697
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CA+kxMuTLCQu9hVd5o-5A=2+08nnKONbPsZ4+pzdwogk1nbPAaA@mail.gmail.com>
References: <CA+kxMuTLCQu9hVd5o-5A=2+08nnKONbPsZ4+pzdwogk1nbPAaA@mail.gmail.com>
Date: Tue, 6 Oct 2015 16:49:40 +0200
Message-ID: <CALLYd6SgzY=U5W0OX5LFKLZ2FTSgyurFxR5njzWn2N9kRhURZw@mail.gmail.com>
To: Dan Ackroyd <danack@basereality.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c3ba82619bc2052170bd97
Subject: Re: [PHP-DEV] [RFC] [DRAFT]: Consistent callables
From: mailto.woden@gmail.com (Daniel Persson)

--001a11c3ba82619bc2052170bd97
Content-Type: text/plain; charset=UTF-8

Hi Dan.

Had this email in the "need-to-read" pile for over a week and finally got
the time to go though the RFC.

Seems like this is something that we need to address. Inconsistencies are
never good.

The only thing I want to point out is that is_callable as well as
method_exists don't state in the manual that the functions or methods
referred is visible.
To make this function implied I think the manual should be updated to state
it.

For instance

public class A {
    private function foo() {}
}

method_exists(new A(), "foo") is technically true.
The method exist but is not visible from your context. For instance when
you use reflection you might want to find any method that exists? Or should
that be handled by the pure reflection API? Either way I think the manual
needs to state this clearly.

Best regards
Daniel

On Tue, Sep 29, 2015 at 4:25 PM, Dan Ackroyd <danack@basereality.com> wrote:

> Hello internals,
>
> Here is a draft RFC to make the callable type in PHP be consistent and
> have much fewer surprises.
>
> https://wiki.php.net/rfc/consistent_callables
>
> This RFC is probably not ready for the formal discussion that is held
> before a vote on it can be held as there may be some more details of
> what changes are necessary lurking, waiting to be found, in the PHP
> source code. However I would like to gather feedback about the
> likelihood of the RFC passing, as implementing a patch for this RFC is
> likely to be a significant amount of work.
>
> And yes most of this RFC targets PHP 8 with only small parts for 7.1.
> I realise that it is easy to think that it's a bit early to start
> thinking about that before 7 is out the door, but as there was a
> stampede of RFCs for PHP 7, I think the earlier RFCs can be discussed
> the better. Depending on the feedback, I imagine I would put this RFC
> up for a formal discussion and vote early in the new year.
>
> cheers
> Dan
> Ack
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--001a11c3ba82619bc2052170bd97--