Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111905
MIME-Version: 1.0
References: <CAJpLVh0K0Mkqa2RP9DLWNXbZJGqhrvJ4CTOWvAkz-7iGENWjYg@mail.gmail.com>
 <71C70A3F-4156-4CFE-B55B-CCE306FB9F0E@newclarity.net>
In-Reply-To: <71C70A3F-4156-4CFE-B55B-CCE306FB9F0E@newclarity.net>
Date: Sat, 19 Sep 2020 09:20:48 +0200
Message-ID: <CAJpLVh2vCWqCtE0YYPQ8LggcpC_8VCfSWn56WABBP+bTts6EZQ@mail.gmail.com>
To: Mike Schinkel <mike@newclarity.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000009a379805afa57530"
Subject: Re: [PHP-DEV] Namespace-private class properties
From: olleharstedt@gmail.com (=?UTF-8?Q?Olle_H=C3=A4rstedt?=)

--0000000000009a379805afa57530
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 18 Sep 2020, 00:13 Mike Schinkel, <mike@newclarity.net> wrote:

>
>
> > On Sep 17, 2020, at 8:28 AM, Olle H=C3=A4rstedt <olleharstedt@gmail.com=
>
> wrote:
> >
> > (NB: This idea is NOT about namespace visibility for classes, interface=
s
> or
> > traits (already discussed here:
> https://wiki.php.net/rfc/namespace-visibility).
> > It's about adding a *new* visibility qualifier, call it "internal", to
> > make properties
> > private inside a namespace. The purpose is to make composition less
> > fragile by not
> > exposing more than necessary.)
> >
> > (NB: This feature exists in Swift, described here:
> > https://docs.swift.org/swift-book/LanguageGuide/AccessControl.html)
> >
> > We have public, protected and private. Since PHP has no module system, =
we
> > have no qualifier to mark a class property as "private for this module"=
.
> > One solution to this could be to add a new qualifier "internal", to mak=
e
> > properties public within the current namespace.
> >
> > Use-cases:
> >
> > * Split data and behaviour into different files and classes
> > * Safely skip getters and setters without risk of properties being abus=
ed
> > by client code
>
> +1
>
> This might be able to address a use-case I have wanted for a while, which
> is to have traits with properties (and methods) that are not accessible
> with the class that uses the trait.
>
> So if a trait is in a different namespace than the using class, the using
> class would not be able to access these "internal" properties.
>
> Or at least I think that could work?
>
> -Mike
>

True, the properties/methods of the trait could be made internal, while
exposing the trait itself (and at least one method, to make it usable).

The question is if PHP tracks the current namespace it's in on each line.
It needs to be known at all times for such an access level to work.

Olle

--0000000000009a379805afa57530--