Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51647
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.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:from:date:message-id:subject:to
         :cc:content-type:content-transfer-encoding;
        b=Vz+st5XXiQd7XZKGnejV65aVq0lhH8HeOIH4o15UTTQ1CrM5l5p2kz9HNf3iXVBlbi
         RCQ30aepeA8J5RZtx/E2VsplJTwwDVUw4lJfh5BeVev5pAHU+DAF4BgPholZhK2gCn1c
         h2H2lUe3RThkzY4iWBXxQcYKpxMHNJxy+hy2w=
MIME-Version: 1.0
In-Reply-To: <8423995CEEEA844CB2F964B14BCA94CD043AC586@PRODEXCHANGE02.ilchildcare.org>
References: <8423995CEEEA844CB2F964B14BCA94CD043ABC80@PRODEXCHANGE02.ilchildcare.org>
 <AANLkTimN6Ws6zM-Egq=eFFeemRN3hOeW9jUih0zg86jg@mail.gmail.com> <8423995CEEEA844CB2F964B14BCA94CD043AC586@PRODEXCHANGE02.ilchildcare.org>
Date: Wed, 9 Mar 2011 10:23:16 -0800
Message-ID: <AANLkTi=Mm-JQLGV95fwOBs3SzcSOyK3HM05W+26vBxP5@mail.gmail.com>
To: Jarrod Nettles <JNettles@inccrra.org>
Cc: Hannes Landeholm <landeholm@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>, 
	"james.butler@edigitalresearch.com" <james.butler@edigitalresearch.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Class Access Modifiers
From: chadfulton@gmail.com (Chad Fulton)

Hello,

On Wed, Mar 9, 2011 at 10:02 AM, Jarrod Nettles <JNettles@inccrra.org> wrot=
e:
> Interesting question. My gut tells me not (as does three years of C# expe=
rience). I=92m sure that everyone will have a different opinion on this but=
 to me it seems taboo that a child class override the visibility of the par=
ent class. For example, PHP currently does not allow you to override a meth=
od 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 throughout=
 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> wrot=
e:
> Currently I'm forced to use huge internal classes for my framework becaus=
e
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