Hi!
> Well, no. The differences are well explained in the deprecation RFC:
>
> https://wiki.php.net/rfc/var_deprecation
"var is currently a simple alias for public. "
> The documentation states the *var* is a substitute for *public* but in
> reality it isn't.
How exactly it isn't? Except for "static"/"const" thing (which is really
a parser glitch and could be easily fixed if anybody cared) I don't see
a difference. Pretending like that static/const thing is a serious issue
that warrants some deep changes makes no sense to me - it's just a very
minor bug.
> It is different to a constant in many ways:
>
> - It is bound to the instance and GCed with it.
Don't see why is it good or why should I care.For all I care it may
never be GCed at all (such as interned strings), and userland developer
should not be worrying about these details anyway.
> - It can be set in the constructor.
> - It can be cloned in __clone.
I find the idea that you have special methods that have magic about
variables not available to other methods rather unwise. And, you forgot
__wakeup for example, unless you're not going to ever serialize your
value object. And maybe other use cases. The point is, you are building
very complex mechanism here that is too magic, and it is going to break
in weird ways because it doesn't work like the rest of language works.
It also promotes bad design, as unless you want to track stack traces,
you'd be able to touch these vars only in magic methods, thus requiring
placing the code dealing with these vars in each of those methods and
only there - you can't put this code in a different method, for example,
because that method won't be magic. So, no refactoring for magic methods.
> public function update(): void {
> $this->changed = new DateTimeImmutable;
> }
I don't see how $created works better than $changed. Moreover, it looks
rather strange that you have getter for $changed but not for $created.
To achieve consistency and avoid confusing people, you probably would
also have getCreated() anyway - which then makes "val" completely redundant.
> To avoid that child classes change the signature of a property from a
> parent class if that is not desired. This is especially useful if you
> intend to use public properties as part of your API or simply want to
I think that's not how it is done by all code I've seen so far - they
use getters instead. Now, we can say we want to get rid of getters, but
then I still don't see what use case final serves. I mean, "final is to
make things unchangeable" is not a use case - it just restating the same
thing in different words. The real question is *why* you need to make
them unchangeable?
> I am not saying that public properties should be part of an API. As I
> wrote already and as Larry Garfield pointed out, having them as part of
> the public API would mean that interfaces should be able to declare them
> and that classes should be able to implement hooks. In other words:
Exactly. So, unless we implement tons of other things, you can't really
use it, and even then it's unclear why you want to use it.
> For the reasons mentioned at the top and in the thread where we
> discussed the deprecation. :)
Well, I see no real reason there and deprecation failed, as it should
have. I don't exactly buy the argument of "we tried to deprecate var,
unsuccessfully, therefore there is a problem with it", and the only real
issue I have seen, as I mentioned above, is that minor static/const
glitch.
> I hope I was able to explain the *var*, *val*, and *final* idea and I
> encourage you to check out Java, Scala, Ceylon, ...
I know about existence of Java, Scala, etc. but "look at Java" is not a
very good explanation - Java is big, so it would be useful to clarify
what exactly I am supposed to be looking at and how it should convince
me with regard to PHP.
Also, I remind that both Java and Scala are compiled fully statically
strict typed languages, and PHP is not.
> would add a lot of benefit but other benefits. The main advantage would
> be that the objects could be considered safe at runtime for concurrency
Which is completely useless for PHP as it does not have
shared-environment concurrency and most likely never will. Also,
experience shows immutable value objects, while nice, does not solve
much of concurrency problems. Data structures are the real problem, and
immutable data structures are way harder to do. Anyway, this is
irrelevant for PHP in any case.
> (not a feature we currently have in PHP but still holds true) and would
> not require one to take care of copy on write all the time.
Err, how? The objects may be immutable but that says nothing of the
values within. So you'd still have to track them.
You could theoretically make some performance gains, maybe, by caching
property lookups, etc. for immutable objects, but I don't think you'd
gain too much compared to what we have now.
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
