Hi,

2016-04-05 12:13 GMT+02:00 Marco Pivetta ocramius@gmail.com:

Hi,

On 5 April 2016 at 12:06, Michał Brzuchalski michal@brzuchalski.com
wrote:

Hi Marco,

Ad. 1 it is posiible to redeclare in a sub-class final property as
non-final, here is some gist presenting my current impl working like:
https://gist.github.com/brzuchal/12ebda1efed59440a78ba43bff116728

It works with public, private and protected properties.

Does this work for public properties as well?

Ad. 2. final means class variable (like static) or class instance
property can not change their reference, it is impossible to replace
zval
in such property, in my opinion immutable is object behavior when
using
some methods you receive newly created (cloned) object which is changed
exactly like DateTimeImmutable
http://php.net/manual/en/datetimeimmutable.add.php

I am aware of what final means in other languages, it just seems that
everyone then needs to translate back and forth from final to
immutable. In addition to that, final has different meaning in
inheritance (re-used keyword), so this adds to the confusion for people
unfamiliar with the feature.

Wiki about Final in Java
https://www.wikiwand.com/en/Final_(Java)#/Final_variables says:

Final variables

A final variable can only be initialized once, either via an initializer or
an assignment statement. It does not need to be initialized at the point of
declaration: this is called a "blank final" variable. A blank final
instance variable of a class must be definitely assigned in every
constructor of the class in which it is declared; similarly, a blank final
static variable must be definitely assigned in a static initializer of the
class in which it is declared; otherwise, a compile-time error occurs in
both cases.[6] (Note: If the variable is a reference, this means that the
variable cannot be re-bound to reference another object. But the object
that it references is still mutable, if it was originally mutable.)

I took the name from Java and only implemented behavior like that, thats wy
I used final.

Ad. 3 it would be awesome if there could be final variables in general,
it would be quite stable if no one could change your variable, AFAIK
zvals
have IMMUTABLE flag which could be used, don't know it for sure I'm
rather
PHP dev than C there would be need some internals guru to ask if it's
posiible.

P.S. We've meet on PHPCon'15 in Poland, thanks for +1.

YW!

Cheers,

Michał Brzuchalski (aka brzuchal)

2016-04-05 11:13 GMT+02:00 Marco Pivetta ocramius@gmail.com:

Hi Michał,

First of all: +1 to this: very useful for value objects!

A few questions:

• can you re-declare a final property in a sub-class, making it
  therefore non-final? (I have reasons to do that, related with altering
  states via mappers)
• do we want to use final, or immutable for these properties?
  final seems to just be a confusing term here.
• is this feature portable to variables in general? I realize that
  adding metadata to ZVals has huge performance implications, but it
  would be
  interesting to do that for performance improvements further down the
  line

Cheers,

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

On 4 April 2016 at 19:53, Michał Brzuchalski michal@brzuchalski.com
wrote:

Hey Internals,

I'm new here. I've been wondering / working on adding final properties
into
PHP lang.

This work started once I had the time to read the "Core Java for
Impateient" by Cay S. Horstmann
and found it very usefull to have final properties like Java.

Those properties differ than const because they can be set at
runtime

but only once in their lifetime.
Such properties could be very usefull in Singletons, ValueObjects etc.
impl
like:

class Money {
public final $amount;
public final $currency;
public function __constructor($amount, $currency) {
$this->amount = $amount;
$this->currency = $currency;
}
}

In above example there is even no need for getter because those
properties
are immutable through
the final keyword, it means those properties cannot change their
references
just like in Java
https://en.wikipedia.org/wiki/Final_(Java)

I've already started some impl on own fork

https://github.com/php/php-src/compare/master...brzuchal:final-properties

I've got some basics in C programming, don't know yet if I can impl it
complex.

I was wondering if it is usefull in yours opinion or is it only my
impression.

I can provide an RFC if it sounds usefull and if I get Wiki karma

Thanks

Michał Brzuchalski (aka brzuchal)

As an additional question: how will this (eventually) play with typed
properties? I am aware that you cannot declare a class named final, but
that may change in future, so better factor it into any possible outcomes
of the RFC.

I don't know if it works with typed properties.
I can provide an RFC but need Wiki Karma (or smth like that) for my account
(login: brzuchal) and don't know how to receive it.

Cheers,

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Cheers,

Michał Brzuchalski (aka brzuchal)

I started a discussion on this a while back, but it fizzled due to not
having an elegant solution for the 'give me a new one of these with these
values changed' problem. I would HIGHLY suggest not using the final
keyword. If final is used as a keyword I would expect it to mean that this
property definition cannot be changed in a child class. See:
https://marc.info/?l=php-internals&m=144766539202647&w=2 Would be happy to
pick this up again and help get the RFC created.

/Sending this again because the mail server was down./

+1 from my side too for this proposal. Retrofitting immutability with
additional keywords is not the nicest thing but PHP has no other way
(same was true for Java when they added it).

Using the final keyword while subclasses are able to override it is
ambiguous in PHP because it already has the notion that something is not
extensible (class) or overridable (method). Hence, I would either use a
different keyword or implement two keywords (and two RFCs):

1. immutable for the functionality you are currently working on.
2. sealed for the above plus type not changeable.
3. final for the above plus not being overridable.

Opening restrictions should be possible as with widening visibility in
inheritance but making something more tight should not because it would
violate the (implicit) interface of the parent class. In other words:

OK
==
immutable -> mutable
sealed -> immutable
sealed -> mutable

Fatal Error
===========
immutable -> sealed
immutable -> final
sealed -> final
final -> immutable
final -> sealed
final -> mutable
mutable -> immutable
mutable -> sealed
mutable -> final

Of course it would be nice to have the possibility to disable these
restrictions while creating fakes, mocks, ... in unit tests. Sadly that
is a feature that we don't have at all in PHP; e.g.:

final class ClassUnderTest {}

mock class TestDouble extends ClassUnderTest {}

I do not think that there should be anything that prevents this new
feature to work nicely together with typed properties. Of course I could
be wrong here but then again it might only require a few adoptions of
that feature to work nicely. One thing is for sure, immutable,
sealed and final would also disallow references (e.g. sorting of an
array); which is a good thing.

--
Richard "Fleshgrinder" Fussenegger

...
(Which leads to "can interfaces define properties", which leads right back to "well what can you do with them", which leads back to the Properties RFC. Which I still want to see happen at some point if at all possible, as it would also subsume this question quite nicely.)

And by Properties RFC you mean Property Accessors Syntax RFC right?
https://wiki.php.net/rfc/propertygetsetsyntax-v1.2

There's an important point here that should not be missed. If these
values are "write once then locked', which I can definitely see as
useful, we need to have another shot at modifying them from __clone().
If not, they are effectively useless for implementing objects in the
style of DateTimeImmutable or the PSR-7 Request/Response objects.
Locking after __construct or __clone (as appropriate) is done is fine,
but if we can't clone-and-modify then I would pretty much never find
value in this feature (no pun intended).

__clone support is indeed extremely important, very good point.

I agree that final seems like a potentially confusing keyword, as every
other use of final (AFAIK) means "subclass cannot change this", but
that's not at all the meaning here.

See other messages of mine in this thread.

Another question, which unfortunately runs straight into the previous
Properties RFC: If a public property is write-once, with the intent
being that it's set from the constructor and then cannot be overridden
but is publicly exposed... shouldn't an interface be able to declare it
as well? It makes public properties safe to use in some cases, but you
can't rely on that safely without an interface.

(Which leads to "can interfaces define properties", which leads right
back to "well what can you do with them", which leads back to the
Properties RFC. Which I still want to see happen at some point if at all
possible, as it would also subsume this question quite nicely.)

I do not see the relation to the RFC (not judging the actual RFC because
I liked the idea but never got into the topic to be able to judge) but I
understand the concern.

In my opinion interfaces in PHP are at the state of Java 7 interfaces
(or even a direct copy) and their functionality must be extended at some
point. Same happened in Java 8.

That being said, I agree that properties should be allowed in
interfaces, however, they must be automatically made final and
immutable (where I proposed the val keyword).

interface Example {

    DateTimeImmutable $created;

    function example();

}

Transforms to:

interface Example {

    final public DateTimeImmutable val $created;

    public function example();

}

Otherwise no consumer could rely on the interface to not change. Also
note that it does not require the RFC you mentioned because no setter,
unset, nor isset is necessary or possible if we handle it like this.

Support for mutable public properties is a different story but allowing
them would destroy the encapsulation and I am against it without anyone
bringing some good arguments that convince me.

--
Richard "Fleshgrinder" Fussenegger

Am 09.04.2016 um 12:55 schrieb Niklas Keller:

Another possible choice would be "readonly".

Rather "writeonce", no?