Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51650
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.42 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type;
        b=tQKlWOvySNGNJXv4UyKhaPAGUsEW583L2lNU3xuieSiL7qgiF4pdPeLysJFYcOViLC
         p5AMSZagrYPxu6B5PPkLG9V276KbME2nIYFp2jxU1aSOTyyUHpn2hbeG1W22mnkY/7pW
         jiUGBBd0k9lpxRpe9RZt6x38wnllQMa9p6Q2w=
MIME-Version: 1.0
In-Reply-To: <AANLkTi=Mm-JQLGV95fwOBs3SzcSOyK3HM05W+26vBxP5@mail.gmail.com>
References: <8423995CEEEA844CB2F964B14BCA94CD043ABC80@PRODEXCHANGE02.ilchildcare.org>
	<AANLkTimN6Ws6zM-Egq=eFFeemRN3hOeW9jUih0zg86jg@mail.gmail.com>
	<8423995CEEEA844CB2F964B14BCA94CD043AC586@PRODEXCHANGE02.ilchildcare.org>
	<AANLkTi=Mm-JQLGV95fwOBs3SzcSOyK3HM05W+26vBxP5@mail.gmail.com>
Date: Wed, 9 Mar 2011 16:33:54 -0300
Message-ID: <AANLkTikjERWZYj9A9W8dusv3Pvwmgw=ASrMAQWChQsMH@mail.gmail.com>
To: Chad Fulton <chadfulton@gmail.com>
Cc: Jarrod Nettles <JNettles@inccrra.org>, Hannes Landeholm <landeholm@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>, 
	"james.butler@edigitalresearch.com" <james.butler@edigitalresearch.com>
Content-Type: multipart/alternative; boundary=20cf3054aa6b361577049e11cf2b
Subject: Re: [PHP-DEV] Class Access Modifiers
From: martinscotta@gmail.com (Martin Scotta)

--20cf3054aa6b361577049e11cf2b
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

class modifiers should follow the same modifiers and semantic that methods:
T_PUBLIC, T_PROTECTED and T_PRIVATE should be used.

nowadays all classes are public...

T_PUBLIC: everybody can see it, everybody can subclass it
T_PROTECTED: visible only within its ns, but everybody can subclass it
T_PRIVATE: visible only within the same ns, subclass allowed only within it=
s
ns

namespace A {
    class Pub { }
    protected class Prot { }
    private class Priv { }
}

namespace B {
    class Foo extends \A\Prot { }  // legal, no matter Foo visibility
    class Baz extends \A\Priv { }  // error, no matter Baz visibility
    new Foo();  // ok
    new Baz();  // ok
    new \A\Pub();  // ok
    new \A\Prot(); // error, class is protected
    new \A\Priv(); // error, class is private
}

in the example "A" exposes classes "Pub" and "Prot", but you cannot
instantiate class "Prot"

So... does it mean that class "Priv" cannot be used outside "A"? no, you ca=
n
always return a reference.

namespace A {
   class F {
    static function getE() { return new E; }
   }
   private class E { }
}

var_dump( \A\F::getE() ); // object \A\E


 Martin Scotta


On Wed, Mar 9, 2011 at 3:23 PM, Chad Fulton <chadfulton@gmail.com> wrote:

> Hello,
>
> On Wed, Mar 9, 2011 at 10:02 AM, Jarrod Nettles <JNettles@inccrra.org>
> wrote:
> > Interesting question. My gut tells me not (as does three years of C#
> experience). I=92m sure that everyone will have a different opinion on th=
is
> but to me it seems taboo that a child class override the visibility of th=
e
> parent class. For example, PHP currently does not allow you to override a
> method with a lower or higher visibility than the parent =96 I can=92t go=
 from
> protected to public or vice versa. Visibility must be maintained througho=
ut
> the class hierarchy.
> >
>
> Actually, class properties and methods can have a higher visibility
> than their parents, just not a lower one.
>
> E.g.:
>
> <?php
>
> error_reporting(E_ALL | E_STRICT);
>
> class foo {
>    protected function bar() {
>
>    }
> }
>
> class baz extends foo {
>    public function bar() {
>
>    }
> }
>
> class foobar extends baz {
>    protected function bar () {
>
>    }
> }
>
> ?>
>
> You get the following error:
>
> Fatal error: Access level to foobar::bar() must be public (as in class
> baz) in ...
>
> -------
>
> That said, I wouldn't think that visibility modifiers on classes need
> to follow the same pattern. In the case of properties and methods, I
> think the rationale is that child classes should be compatible from an
> interface standpoint with their parents. That same logic may not
> transfer to class visibility modifiers.
>
> I am certainly no expert, but I'm curious what the use case is for
> class visibility modifiers?
>
> On Wed, Mar 9, 2011 at 7:11 AM, Hannes Landeholm <landeholm@gmail.com>
> wrote:
> > Currently I'm forced to use huge internal classes for my framework
> because
> dividing them into smaller classes would expose internal behavior to the
> "outside"... the application layer.
> >
>
> This doesn't necessarily make sense to me. Isn't it the
> end-developer's problem if they start instantiating classes in weird
> ways?
>
> It doesn't seem the same as having a private method, since in that
> case the end-developer presumably already has an object instance, and
> you want to guide them to the correct interface for interacting with
> it, whereas in an application, one would think that the end-developer
> wouldn't simply be instantiating classes by themselves all over the
> place.
>
> Chad
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--20cf3054aa6b361577049e11cf2b--