Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88093
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAObuZdvijL5SnZ5rgtcz3_6B=vU7jPA70BAphCG_gKHBwmE+Qw@mail.gmail.com>
References: <20150827173432.GA71000@3006.local>
	<28.A5.59944.15C7CE55@pb1.pair.com>
	<55ED368C.5010209@gmail.com>
	<CAObuZdvijL5SnZ5rgtcz3_6B=vU7jPA70BAphCG_gKHBwmE+Qw@mail.gmail.com>
Date: Mon, 7 Sep 2015 06:27:22 -0600
Message-ID: <CAObuZdsXo3TLjcUg1wMAaaWNSbHiS_R4B8vi0m9ukmoZ9uGSdQ@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c2775c0fa042051f275fd0
Subject: Re: [PHP-DEV] Re: [RFC] [Concept] Class Constant visibility modifiers
 in PHP 7.1+
From: derokorian@gmail.com (Ryan Pallas)

--001a11c2775c0fa042051f275fd0
Content-Type: text/plain; charset=UTF-8

On Mon, Sep 7, 2015 at 6:24 AM, Ryan Pallas <derokorian@gmail.com> wrote:

>
>
> On Mon, Sep 7, 2015 at 1:02 AM, Stanislav Malyshev <smalyshev@gmail.com>
> wrote:
>
>> Hi!
>>
>> > Funny you should propose this now, I was wanting this feature just the
>> > other day. This would be a useful addition, and clean up a strange
>> > inconsistency: why can methods and properties have visibility modifiers,
>> > but not constants?
>>
>> Private and protected methods and properties are private for a reason -
>> they may be radically changed or gone when the code is changing, and
>> thus external code should not rely on them, and the way to ensure it is
>> to deny that code access to them. However, I have hard time seeing how
>> that would apply to constants - they shouldn't really change, and if
>> they do, they either shouldn't be constant, or something in your world
>> changed fundamentally (i.e. scientists discovered that PI actually
>> equals to 4). I wonder if you find in your code constant that you need
>> to hide because you foresee it changing - should it really be a constant
>> at all?
>>
>
>
> For me a common use case is DB abstraction. I have an abstract base class
> that implements a bunch of functionality based on protected static members,
> which are to be set in the implementing class. Now these properties are
> constant for the implementing class (table name, column definition, etc)
>  but I have to put them in a static member to prevent outside access. So
> now I have the problem, where if someone else maintains my code they see a
> static member in the class they may think its acceptable to change it in
> some function at run time, meanwhile if they were constants it would be
> very obvious that they should not be changed. The reason they are in static
> members is A) to provide visibility modifiers and B) to share a single
> value across all instances, however given that C) they are constant through
> meaning and usage, the should instead be protected consts. For an example
> of a base class of this type, you can look at my framework's version (NOTE:
> I'm not advocating my framework, its kinda crap but it works well for my
> purposes) http://bit.ly/1EN59Ty (class) http://bit.ly/1NdkGgL (docs)
>
Looks like I changed to constants because someone did write a function that
modified the value of TABLE_NAME in a project I was working on. So now the
internals of the models are available everywhere (sad).


> I fully support this idea, and would be glad to provide any help I can
> (though that probably just means writing tests since I don't know C)
>

--001a11c2775c0fa042051f275fd0--