Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111896
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
In-Reply-To: <CAJpLVh0K0Mkqa2RP9DLWNXbZJGqhrvJ4CTOWvAkz-7iGENWjYg@mail.gmail.com>
Date: Thu, 17 Sep 2020 18:13:41 -0400
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <71C70A3F-4156-4CFE-B55B-CCE306FB9F0E@newclarity.net>
References: <CAJpLVh0K0Mkqa2RP9DLWNXbZJGqhrvJ4CTOWvAkz-7iGENWjYg@mail.gmail.com>
To: =?utf-8?Q?Olle_H=C3=A4rstedt?= <olleharstedt@gmail.com>
Subject: Re: [PHP-DEV] Namespace-private class properties
From: mike@newclarity.net (Mike Schinkel)



> On Sep 17, 2020, at 8:28 AM, Olle H=C3=A4rstedt =
<olleharstedt@gmail.com> wrote:
>=20
> (NB: This idea is NOT about namespace visibility for classes, =
interfaces 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.)
>=20
> (NB: This feature exists in Swift, described here:
> https://docs.swift.org/swift-book/LanguageGuide/AccessControl.html)
>=20
> 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 =
make
> properties public within the current namespace.
>=20
> Use-cases:
>=20
> * Split data and behaviour into different files and classes
> * Safely skip getters and setters without risk of properties being =
abused
> 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. =20

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. =20

Or at least I think that could work?

-Mike

>=20
> Tiny example:
>=20
> ```
> namespace App\User;
> class User {
>  internal $username;
>  internal $password;
> }
>=20
> namespace App\User\Services;
> class ProcessUser {
>  // Child namespace has access to internal properties,
>  // but App\ has not.
> }
> ```
>=20
> Possible?
>=20
> Olle
>=20