Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69481
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pthreads.org from 74.125.82.50 cause and error)
Message-ID: <524EB99E.4040307@pthreads.org>
Date: Fri, 04 Oct 2013 13:50:38 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: Clint Priest <cpriest@php.net>
CC: internals@lists.php.net
References: <5D.40.07863.EB798425@pb1.pair.com> <524EA254.1000109@php.net>
In-Reply-To: <524EA254.1000109@php.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RFC: Draft: Nested Classes
From: pthreads@pthreads.org (Joe Watkins)

On 10/04/2013 12:11 PM, Clint Priest wrote:
> On 9/29/2013 4:12 PM, Joe Watkins wrote:
>> https://wiki.php.net/rfc/nested_classes
> One issue I see from a maintenance perspective (of the user of this 
> feature) is that you could end up having files with dozens of classes, 
> it would be nice if it dot have to be embedded within the class but 
> rather kept in a separate file.
>
> Alternatives:
>
> foo.php
> --------
>     namespace s;
>
>     class foo {
>     }
>
> bar.php
> --------
> namespace s;
>
>     private class bar {
>         public for s\foo;
>     }
>
> /* This has the advantage of access control being kept in the 
> declaring class (bar) */
>
> ----------------------------
>
> foo.php
> --------
>     namespace s;
>
>     class foo {
>         use s\foo as private;
>     }
>
> bar.php
> --------
>     namespace s;
>
>     private class bar {
>     }
>
> /* This has no real advantage over the prior alternative but just 
> another possibility */
>
> ----------------------------
>
> Ultimately I like the feature, even if it could only be done in a 
> nested fashion.  Given the original proposal, could something like 
> this work?
>
> bar.php:
> --------
>     abstract class abs_bar {
>     }
>
> foo.php:
> --------
>     class foo {
>         private bar extends abs_bar {
>         }
>     }
>
> -Clint
>
Morning,

     I've heard the multiple files thing several times now ... while I 
like the idea, I think it might just confuse users, what would a 
namespace be if classes supported this .... I think let's not stand on 
the toes of namespaces, it also goes contrary to the best use case of 
the feature, if we leave it out then it cannot be abused or cause 
confusion ...

     This simplifies the use of classes with a modified visibility I 
think, because we can define rules that are class-centric:

         private class: available to any class in the same virtual namespace
         protected class: available to any class in the same global class
         public class: available to any class

     Note: ("class" includes interfaces, traits, and abstracts, they can 
all be nested and declared with modified visibility too)

         private static method: available to any class is the same 
virtual namespace
         protected static method: available to any class in the same 
global class
         public static method: available to any class

     I don't think we should touch the functionality of normal method 
calls or member access, though static member access may need adjustment ...

     I've had a degree of success getting access to everything from 
anywhere, so I'm open to well thought out ideas there ...

     This is the clearest definition that I can think up and make work 
right now, it means that from the level of the global class outward to 
the namespace, all the way to the global scope, nothing is touched, 
everything is still the same. The only changes, and the only place those 
changes have any impact are at the level of the class, outside of a 
global class it's operation and inheritance as usual. From the global or 
namespace perspective a public nested class is just a namespaced class, 
the rest, it is not even aware of.

     Ultimately, I think your last example will be the solution to large 
projects utilizing nested classes, where they feel they must cross the 
file boundary: normal inheritance where the final/concrete classes are 
nested, sharing among them common public abstracts/interfaces from some 
other scope/namespace. This more or less keeps intact the black box, 
since access to abstracts/interfaces directly is not useful, and the 
final implementations are kept private by nesting.

     There appears to be a feeling that things are moving a bit too fast 
for 5.6, I feel obliged to delay this and anonymous classes until 5.7, 
if anyone has any input, I'll be opening the vote on monday or tuesday 
next week for anonymous classes, I'm considering delaying both until 5.7 ...

Cheers
Joe