FAQ
Has there been any discussion on access modifiers for classes? I looked through the existing RFCs and searched through old discussions on the mailing list but didn't come up with anything.

Specifically, I think it would be beneficial (for framework developers in particular) if classes could be marked as public, private, etc. I haven't really thought through exact definitions on how each modifier would restrict but here is a use case.

A developer is working on an object-oriented framework that uses namespaces and uses classes extensively. He considers many of the classes to be for internal use only, that is, they will only be used by the internal workings of the framework core, not by any web application that somebody builds using his framework. That being the case, the developer would like to restrict access to certain classes so that they can only be accessed in certain situations.

Proposal (after five minutes of thought)


1. Public - A class can be instantiated or called statically from anywhere. For reasons of backward compatibility a class without any modifier would be considered public.

2. Internal - A class can only be instantiated/called from within the same root namespace. If I have a class Core\Mvc\View, only from within a class sharing the same root namespace (ex: Core\Html\Textbox) would I be able to access the "View" class.

3. Private - A class can only be instantiated/called from within the exact same namespace. Example, class Core\Mvc\View could only be accessed from a class in the Core\Mvc namespace (ex: Core\Mvc\Controller).

What do people think? I'm not too concerned with the exact three I listed above, but more and more I think it would be wise if there were a way to restrict the accessibility of classes between namespaces.

Jarrod Nettles
Application Developer - Technology
INCCRRA
p 309.829.5327 - f 309.828.1808

This e-mail message may contain privileged or confidential information. If you are not the intended recipient, you may not disclose, use, disseminate, distribute, copy or rely upon this message or attachment in any way. If you received this e-mail message in error, please return by forwarding the message and its attachments to the sender. INCCRRA does not accept liability for any errors, omissions, corruption or virus in the contents of this message or any attachments that arises as a result of e-mail transmission.

Please consider your environmental responsibility before printing this e-mail

Search Discussions

  • Martin Scotta at Mar 3, 2011 at 6:09 pm
    I'm writing a RFC about improvements on the current OO Model.

    do you want to add this?

    http://wiki.php.net/rfc/object-model-improvements

    Martin Scotta

    On Thu, Mar 3, 2011 at 2:21 PM, Jarrod Nettles wrote:

    Has there been any discussion on access modifiers for classes? I looked
    through the existing RFCs and searched through old discussions on the
    mailing list but didn't come up with anything.

    Specifically, I think it would be beneficial (for framework developers in
    particular) if classes could be marked as public, private, etc. I haven't
    really thought through exact definitions on how each modifier would restrict
    but here is a use case.

    A developer is working on an object-oriented framework that uses namespaces
    and uses classes extensively. He considers many of the classes to be for
    internal use only, that is, they will only be used by the internal workings
    of the framework core, not by any web application that somebody builds using
    his framework. That being the case, the developer would like to restrict
    access to certain classes so that they can only be accessed in certain
    situations.

    Proposal (after five minutes of thought)


    1. Public - A class can be instantiated or called statically from
    anywhere. For reasons of backward compatibility a class without any modifier
    would be considered public.

    2. Internal - A class can only be instantiated/called from within the
    same root namespace. If I have a class Core\Mvc\View, only from within a
    class sharing the same root namespace (ex: Core\Html\Textbox) would I be
    able to access the "View" class.

    3. Private - A class can only be instantiated/called from within the
    exact same namespace. Example, class Core\Mvc\View could only be accessed
    from a class in the Core\Mvc namespace (ex: Core\Mvc\Controller).

    What do people think? I'm not too concerned with the exact three I listed
    above, but more and more I think it would be wise if there were a way to
    restrict the accessibility of classes between namespaces.

    Jarrod Nettles
    Application Developer - Technology
    INCCRRA
    p 309.829.5327 - f 309.828.1808

    This e-mail message may contain privileged or confidential information. If
    you are not the intended recipient, you may not disclose, use, disseminate,
    distribute, copy or rely upon this message or attachment in any way. If you
    received this e-mail message in error, please return by forwarding the
    message and its attachments to the sender. INCCRRA does not accept liability
    for any errors, omissions, corruption or virus in the contents of this
    message or any attachments that arises as a result of e-mail transmission.

    Please consider your environmental responsibility before printing this
    e-mail
  • Jarrod Nettles at Mar 8, 2011 at 9:27 pm
    Either that or it should be spun off into its own RFC. I have no idea how to do either.

    From: Martin Scotta
    Sent: Thursday, March 03, 2011 12:09 PM
    To: Jarrod Nettles
    Cc: internals@lists.php.net
    Subject: Re: [PHP-DEV] Class Access Modifiers

    I'm writing a RFC about improvements on the current OO Model.

    do you want to add this?

    http://wiki.php.net/rfc/object-model-improvements

    Martin Scotta

    On Thu, Mar 3, 2011 at 2:21 PM, Jarrod Nettles wrote:
    Has there been any discussion on access modifiers for classes? I looked through the existing RFCs and searched through old discussions on the mailing list but didn't come up with anything.

    Specifically, I think it would be beneficial (for framework developers in particular) if classes could be marked as public, private, etc. I haven't really thought through exact definitions on how each modifier would restrict but here is a use case.

    A developer is working on an object-oriented framework that uses namespaces and uses classes extensively. He considers many of the classes to be for internal use only, that is, they will only be used by the internal workings of the framework core, not by any web application that somebody builds using his framework. That being the case, the developer would like to restrict access to certain classes so that they can only be accessed in certain situations.

    Proposal (after five minutes of thought)


    1. Public - A class can be instantiated or called statically from anywhere. For reasons of backward compatibility a class without any modifier would be considered public.

    2. Internal - A class can only be instantiated/called from within the same root namespace. If I have a class Core\Mvc\View, only from within a class sharing the same root namespace (ex: Core\Html\Textbox) would I be able to access the "View" class.

    3. Private - A class can only be instantiated/called from within the exact same namespace. Example, class Core\Mvc\View could only be accessed from a class in the Core\Mvc namespace (ex: Core\Mvc\Controller).

    What do people think? I'm not too concerned with the exact three I listed above, but more and more I think it would be wise if there were a way to restrict the accessibility of classes between namespaces.

    Jarrod Nettles
    Application Developer - Technology
    INCCRRA
    p 309.829.5327 - f 309.828.1808

    This e-mail message may contain privileged or confidential information. If you are not the intended recipient, you may not disclose, use, disseminate, distribute, copy or rely upon this message or attachment in any way. If you received this e-mail message in error, please return by forwarding the message and its attachments to the sender. INCCRRA does not accept liability for any errors, omissions, corruption or virus in the contents of this message or any attachments that arises as a result of e-mail transmission.

    Please consider your environmental responsibility before printing this e-mail


    Jarrod Nettles
    Application Developer - Technology
    INCCRRA
    p 309.829.5327 - f 309.828.1808

    This e-mail message may contain privileged or confidential information. If you are not the intended recipient, you may not disclose, use, disseminate, distribute, copy or rely upon this message or attachment in any way. If you received this e-mail message in error, please return by forwarding the message and its attachments to the sender. INCCRRA does not accept liability for any errors, omissions, corruption or virus in the contents of this message or any attachments that arises as a result of e-mail transmission.

    Please consider your environmental responsibility before printing this e-mail
  • Hannes Landeholm at Mar 9, 2011 at 3:11 pm
    Good Sugesstion.

    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 would solve that problem.

    ~Hannes

    On 3 March 2011 18:21, Jarrod Nettles wrote:

    Has there been any discussion on access modifiers for classes? I looked
    through the existing RFCs and searched through old discussions on the
    mailing list but didn't come up with anything.

    Specifically, I think it would be beneficial (for framework developers in
    particular) if classes could be marked as public, private, etc. I haven't
    really thought through exact definitions on how each modifier would restrict
    but here is a use case.

    A developer is working on an object-oriented framework that uses namespaces
    and uses classes extensively. He considers many of the classes to be for
    internal use only, that is, they will only be used by the internal workings
    of the framework core, not by any web application that somebody builds using
    his framework. That being the case, the developer would like to restrict
    access to certain classes so that they can only be accessed in certain
    situations.

    Proposal (after five minutes of thought)


    1. Public - A class can be instantiated or called statically from
    anywhere. For reasons of backward compatibility a class without any modifier
    would be considered public.

    2. Internal - A class can only be instantiated/called from within the
    same root namespace. If I have a class Core\Mvc\View, only from within a
    class sharing the same root namespace (ex: Core\Html\Textbox) would I be
    able to access the "View" class.

    3. Private - A class can only be instantiated/called from within the
    exact same namespace. Example, class Core\Mvc\View could only be accessed
    from a class in the Core\Mvc namespace (ex: Core\Mvc\Controller).

    What do people think? I'm not too concerned with the exact three I listed
    above, but more and more I think it would be wise if there were a way to
    restrict the accessibility of classes between namespaces.

    Jarrod Nettles
    Application Developer - Technology
    INCCRRA
    p 309.829.5327 - f 309.828.1808

    This e-mail message may contain privileged or confidential information. If
    you are not the intended recipient, you may not disclose, use, disseminate,
    distribute, copy or rely upon this message or attachment in any way. If you
    received this e-mail message in error, please return by forwarding the
    message and its attachments to the sender. INCCRRA does not accept liability
    for any errors, omissions, corruption or virus in the contents of this
    message or any attachments that arises as a result of e-mail transmission.

    Please consider your environmental responsibility before printing this
    e-mail
  • James Butler at Mar 9, 2011 at 3:18 pm

    Proposal (after five minutes of thought)


    1. Public - A class can be instantiated or called statically from
    anywhere. For reasons of backward compatibility a class without any modifier
    would be considered public.

    2. Internal - A class can only be instantiated/called from within the
    same root namespace. If I have a class Core\Mvc\View, only from within a
    class sharing the same root namespace (ex: Core\Html\Textbox) would I be
    able to access the "View" class.

    3. Private - A class can only be instantiated/called from within the
    exact same namespace. Example, class Core\Mvc\View could only be accessed
    from a class in the Core\Mvc namespace (ex: Core\Mvc\Controller).

    What do people think? I'm not too concerned with the exact three I listed
    above, but more and more I think it would be wise if there were a way to
    restrict the accessibility of classes between namespaces.

    Jarrod Nettles
    Really like the general idea and think (IMHO) its RFC worthy, but have a
    few questions...
    Would there be any method of overriding the the visibility in a child
    class?And would the child class inherit the parents visibility?
    I realise this may seem daft initially but I can think of some instances
    where this might be useful.

    James
  • Jarrod Nettles at Mar 9, 2011 at 6:02 pm
    Interesting question. My gut tells me not (as does three years of C# experience). I’m 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 parent class. For example, PHP currently does not allow you to override a method with a lower or higher visibility than the parent – I can’t go from protected to public or vice versa. Visibility must be maintained throughout the class hierarchy.

    I realize that ten thousand people will curse up and down the first time they try to extend an internal class with a public one but good application design should be the real solution.

    Proposal (after five minutes of thought)


    1. Public - A class can be instantiated or called statically from
    anywhere. For reasons of backward compatibility a class without any modifier
    would be considered public.

    2. Internal - A class can only be instantiated/called from within the
    same root namespace. If I have a class Core\Mvc\View, only from within a
    class sharing the same root namespace (ex: Core\Html\Textbox) would I be
    able to access the "View" class.

    3. Private - A class can only be instantiated/called from within the
    exact same namespace. Example, class Core\Mvc\View could only be accessed
    from a class in the Core\Mvc namespace (ex: Core\Mvc\Controller).

    What do people think? I'm not too concerned with the exact three I listed
    above, but more and more I think it would be wise if there were a way to
    restrict the accessibility of classes between namespaces.

    Jarrod Nettles
    Really like the general idea and think (IMHO) its RFC worthy, but have a
    few questions...
    Would there be any method of overriding the the visibility in a child
    class?And would the child class inherit the parents visibility?
    I realise this may seem daft initially but I can think of some instances
    where this might be useful.

    James

    Jarrod Nettles
    Application Developer - Technology
    INCCRRA
    p 309.829.5327 - f 309.828.1808

    This e-mail message may contain privileged or confidential information. If you are not the intended recipient, you may not disclose, use, disseminate, distribute, copy or rely upon this message or attachment in any way. If you received this e-mail message in error, please return by forwarding the message and its attachments to the sender. INCCRRA does not accept liability for any errors, omissions, corruption or virus in the contents of this message or any attachments that arises as a result of e-mail transmission.

    Please consider your environmental responsibility before printing this e-mail
  • Chad Fulton at Mar 9, 2011 at 6:23 pm
    Hello,
    On Wed, Mar 9, 2011 at 10:02 AM, Jarrod Nettles wrote:
    Interesting question. My gut tells me not (as does three years of C# experience). I’m 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 parent class. For example, PHP currently does not allow you to override a method with a lower or higher visibility than the parent – I can’t 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 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
  • Martin Scotta at Mar 9, 2011 at 7:34 pm
    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 its
    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 can
    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 wrote:

    Hello,
    On Wed, Mar 9, 2011 at 10:02 AM, Jarrod Nettles wrote:
    Interesting question. My gut tells me not (as does three years of C#
    experience). I’m 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
    parent class. For example, PHP currently does not allow you to override a
    method with a lower or higher visibility than the parent – I can’t 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 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
  • Martin Scotta at Mar 9, 2011 at 7:43 pm

    On Wed, Mar 9, 2011 at 3:23 PM, Chad Fulton wrote:

    Hello,
    On Wed, Mar 9, 2011 at 10:02 AM, Jarrod Nettles wrote:
    Interesting question. My gut tells me not (as does three years of C#
    experience). I’m 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
    parent class. For example, PHP currently does not allow you to override a
    method with a lower or higher visibility than the parent – I can’t 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.
    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 too
    .



    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 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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedMar 3, '11 at 5:21p
activeMar 9, '11 at 7:43p
posts9
users5
websitephp.net

People

Translate

site design / logo © 2022 Grokbase