Edit report at https://bugs.php.net/bug.php?id=46506&edit=1
ID: 46506
Comment by: stian dot pedersen at gmail dot com
Reported by: glideraerobatics at hotmail dot com
Summary: readonly attribute for (public) class variables
Status: Open
Type: Feature/Change Request
Package: *General Issues
PHP Version: 5.4
Block user comment: N
Private report: N
New Comment:
It is especially useful for IDE. __get and __set work horribly with, for
instance,
PhpStorm, arguably the best current PHP IDE.
I would like to see "type hinting" applied to variables as well.
private Object $object. Currently, i will have to do /** @var Object $object */
above to get correct code completion, which violates DRY and is inelegant.
Finally, namespace visibility and some stricter language rules, and maybe PHP
may
actually be suited for large application web development.
Previous Comments:
------------------------------------------------------------------------
[2013-07-05 00:37:26] dave at shax dot com
'readonly' property as described here would be extremely useful to me
in daily development.
Doesn't need to be fancy. The most obvious functionality, as described
by others above, is exactly what I want. At the moment, I duplicate
this functionality in 90% my classes using __get().
There's presumably a bit of a performance knock in doing it with
__get() (never benchmarked it, but it seems obvious) - not routing
the read requests for each property through __get() or a separate
getter function saves a function call and would be faster.
Because I currently use __get() on nearly every major object in my
application, I could easily save several hundred function calls per
request, which is probably creating a measurable difference in page
generation.
It may seem CRAZY to accept performance slowdown for something this
trivial, but for me having each object defined as an individual solid
API in its own right makes my code much more stable, and in a large
application prevents unwanted/accidental interference from outside
modules. It's mainly about being SUPER sure I've internally validated
all data that's entering each object - hardening it!
At the moment my options are to make it writable by anyone, or accept
a performance hit - this is why I'm very keen for this to be added to
the language!
For the implementation of this, I'd want it to be like 'protected',
not 'private' wherein other classes that inherit the property can
also write to it.
------------------------------------------------------------------------
[2013-03-31 09:09:16] glideraerobatics at hotmail dot com
@stian dot pedersen at gmail dot com
A "property" keyword isn't good enough because you still need the scope
keywords
public and protected at least. That's why I used the C# convention in the 1st
post.
------------------------------------------------------------------------
[2013-03-30 18:40:43] stian dot pedersen at gmail dot com
This feature is seconded. Basically it would be useful to have a modifier which
allows internal modification but disallows public reassignment. By an example,
letting "property" be the new key word,
class Order
{
property $customer;
}
class Order
{
private $customer;
public getCustomer(){return $this->customer;}
}
$order->customer and $order->getCustomer() could have the same semantics in
that
a "copy of the pointer" in C terms is returned and you cannot call $order-
>customer = null any more than you could call $order->getCustomer() = null.
However, $customer itself should be modifyable, for instance, $order->customer-
>id = 1000, if id is declared as public. This would be more in tune of mat dot
barrie at gmail dot com and very useful in OOP.
Inside the class, I would prefer to be able to reassign customer at will (even
after constructor).
Syntactically it would be nice to chose a syntax that would allow support for
setters also, but for now, I would be happy with this. It sorta does the same
thing as the __get() trick but does not mess up IDE support and will probably
execute faster.
------------------------------------------------------------------------
[2012-11-27 15:55:04] info at strictcoding dot co dot uk
+1 for this awesome feature. Any reviews from the PHP team?
------------------------------------------------------------------------
[2012-09-18 21:53:20] mat dot barrie at gmail dot com
As a point of interest, the C# readonly keyword mentioned actually does not
protect exposed classes from being modified, it prevents assignment. So from
your example if you duplicate the C# behaviour, this is what it actually would
work like this, which I don't think is what you're asking for:
--
$count = count($parent->children); // You can do this
$name = $parent->children[0]; // You can even do this
$parent->children[0] = "BILLY"; // You can still do this
$parent->children[] = "BOB"; // And you can still even do this
$parent->children = NULL; // But not this
unset($parent->children); // Or this
--
A readonly attribute probably isn't what's needed here (after all, you're not
actually asking for a property that can be made readonly) but instead if the
protection level could be defined on the getter and setter independently, so
that set could be defined as private and get as public. __get and __set sort
of
do this, but they're useless if you're serialising, hurt performance, and
unless
I'm missing something you can't add phpDoc comments to the exposed pseudo-
properties.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=46506
--
Edit this bug report at https://bugs.php.net/bug.php?id=46506&edit=1
