Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88078
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pthreads.org from 209.85.160.172 cause and error)
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 08:15:19 +0100
Message-ID: <CAL=_i_mSj4x_EUmUQq-_VrEFALgrsOOaz0+R3y_=P8WRABzpHw@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113a6a7617fa9c051f2303be
Subject: Re: [PHP-DEV] Re: [RFC] [Concept] Class Constant visibility modifiers
 in PHP 7.1+
From: pthreads@pthreads.org (Joe Watkins)

--001a113a6a7617fa9c051f2303be
Content-Type: text/plain; charset=UTF-8

> However, I have hard time seeing how that would apply to constants

I don't see what their not changing has to do with their visibility.

It's not hard to see a legitimate use case for private constants, a case
that springs to mind is where you use a public bitmask for some
configuration option but want to keep the shift or mask constants private,
because they might change, and you don't want to leak that implementation
detail. They are still constant at runtime, but over the course of the life
of the codebase they can definitely change, and, they shouldn't be a static
member or normal variable.



On Mon, Sep 7, 2015 at 8: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?
> --
> Stas Malyshev
> smalyshev@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--001a113a6a7617fa9c051f2303be--