Hello, internals!
2015-02-01 4:01 GMT+03:00 Andrea Faulds <a...@ajf.me>:
> I think having some means to create value type classes (i.e. PHP 4-style
> classes) would be beneficial. These classes would have the same always-copy
> or copy-on-write behaviour that PHP’s scalar types and arrays have. They’d
> be performant compared to immutable classes like PSR-7’s, because
> operations mutate the value in-place if possible, rather than creating a
> new class. They’d also be nicer to use, because you can change the value
> imperatively rather than having to chain together return values. But you
> keep the main advantages of immutable types: no spooky action at a
> distance, no explicit copying needed.
Agree in that point with you, this can be a good instrument if implemented
in PHP. I see a good point in it by using this with interfaces and "const"
modifier for parameters:
class Foo {
public function bar(const Baz $object); // Require an instance to be
passed as copy
}
This should be used as weakly immutability for places where changes of
object is not expected. However, we can call methods on $objet, e.g.
setters.
The same will be useful for simple object variables:
const $object = new stdClass;
$object = 123; // Exception, can not change const variable
$object->field = 456; // Exception, can not change public properties for
const objects
$anotherObject = $object; // Copy on write
$anotherObject->field = 123; // ok to change local copy
However, we should not worry about setters (if present):
class MutableObject {
public $field = 42;
public function setField(const integer $newValue) {
$this->field = $newValue;
}
}
// let's create immutable object instance for that
const $instance = new MutableObject();
$instance->field = 56; // Exception, can not change public properties for
const objects
// BUT, no checks for setters
$instance->setField(56);
echo $instance->field; // outputs 56
I think temporary immutability for objects can solve a lot of extra checks.
For example, my previous code allows to drop extra getters
($instance->getField()) for simple classes, when we just want to work on
our local copy of object in read-only mode. With this feature
DateTimeImmutable functionality can be implemented like that:
const $now = new DateTime();
$future = $now; // Copy on write
$future->modify('+1 day'); // only $future variable is modified
echo $now->format(DATE_RFC822); // unchanged
On 1 Feb 2015, at 00:55, Stanislav Malyshev <smalys...@gmail.com> wrote:
> For all this, I'd like to ask - why? Immutable object are very useful in
> concurrency applications, since they allow to avoid expensive
> synchronization costs and make it much easier to reason about system's
> state (which is arguably impossible to predict with mutable objects in a
> parallel system). But PHP has no parallelism. So which benefit would
> that provide? If you want an immutable object, just make all properties
> protected and provide getters but not setters. This is easily doable
> without any keywords.
Yes, parallelism is not present in PHP (except pthreads extension), so this
requirement for temporary immutability of variables is less than in
multi-threaded applications with IPC. But I think that main advantage of
this modifier (immutable) is to add extra protection and assumption for
developers to bypass extra getters (sorry, Doctrine) and to allow more
safer code.
Passing a copy of object (should this be deeper clone or not?) as an
argument to the function is nice feature too, IMO. We *explicitly* mark an
argument as immutable for method body, so no direct changes will be
performed on this instance and no overhead for calling getters.
Should I try to write an RFC for that?
