Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88092
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <55ED368C.5010209@gmail.com>
References: <20150827173432.GA71000@3006.local>
	<28.A5.59944.15C7CE55@pb1.pair.com>
	<55ED368C.5010209@gmail.com>
Date: Mon, 7 Sep 2015 06:24:24 -0600
Message-ID: <CAObuZdvijL5SnZ5rgtcz3_6B=vU7jPA70BAphCG_gKHBwmE+Qw@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=bcaec550ac7e758908051f275462
Subject: Re: [PHP-DEV] Re: [RFC] [Concept] Class Constant visibility modifiers
 in PHP 7.1+
From: derokorian@gmail.com (Ryan Pallas)

--bcaec550ac7e758908051f275462
Content-Type: text/plain; charset=UTF-8

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)

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)

--bcaec550ac7e758908051f275462--