Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51652
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.170 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=BiVNy8qD1SW7Q0MiU1rfRZ5YhLFBCKWQK18VR2+UA063JRnR66KUQrWhifUkiPiCkw
         0VQYGLJD8ksJffZUi3Sey4C7Z9VwF8nhc1WOrsD1uLLFHXi+AlDbijWjiLYKPMXvGOk+
         kPbDP8nyCI6SQOKbPmsIlKUY0ubKPFdGiUtKc=
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:43:01 -0300
Message-ID: <AANLkTi=d3RGp4qa7p12j8Uq5qFUEUi53zbs8jGf+7OWX@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=20cf307c9e14c5d6f6049e11efb9
Subject: Re: [PHP-DEV] Class Access Modifiers
From: martinscotta@gmail.com (Martin Scotta)

--20cf307c9e14c5d6f6049e11efb9
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

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.
>

yes, every class should specify its own visibility.
Inheritance here does not make any sense, you only will be able to use
private classes at the cost of your entire class hierarchy being private to=
o
.




>
> 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?
>

Well, that depends on who is your end-user?
Current object model works well for small-to-mid size application, but it
does not allows to write *safe* libraries

safe: to don't break client code, because of wrong client code.


> 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
>
>

--20cf307c9e14c5d6f6049e11efb9--