Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111906
MIME-Version: 1.0
References: <CAJpLVh0K0Mkqa2RP9DLWNXbZJGqhrvJ4CTOWvAkz-7iGENWjYg@mail.gmail.com>
 <71C70A3F-4156-4CFE-B55B-CCE306FB9F0E@newclarity.net> <CAJpLVh2vCWqCtE0YYPQ8LggcpC_8VCfSWn56WABBP+bTts6EZQ@mail.gmail.com>
In-Reply-To: <CAJpLVh2vCWqCtE0YYPQ8LggcpC_8VCfSWn56WABBP+bTts6EZQ@mail.gmail.com>
Date: Sat, 19 Sep 2020 13:01:19 +0200
Message-ID: <CAJpLVh2xrORwYap8U0GJUDcH9iktavEzs5uKWL6jb3ab3q0jhA@mail.gmail.com>
To: Mike Schinkel <mike@newclarity.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000520b6c05afa88a29"
Subject: Re: [PHP-DEV] Namespace-private class properties
From: olleharstedt@gmail.com (=?UTF-8?Q?Olle_H=C3=A4rstedt?=)

--000000000000520b6c05afa88a29
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, 19 Sep 2020, 09:20 Olle H=C3=A4rstedt, <olleharstedt@gmail.com> wro=
te:

>
> 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.co=
m>
>> wrote:
>> >
>> > (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.)
>> >
>> > (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 ma=
ke
>> > 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
>> abused
>> > by client code
>>
>> +1
>>
>> This might be able to address a use-case I have wanted for a while, whic=
h
>> 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 usin=
g
>> 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
>

Just discovered that this feature already exists in Psalm, @psalm-internal.
They are streets ahead. :)

Olle

>

--000000000000520b6c05afa88a29--