On 4/13/2016 10:18 PM, Stanislav Malyshev wrote: > 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. >
Possible approach, yes. Still a huge inconsistency with function
declarations and their access modifiers (*var function*?!?). Just look
at the special definitions in the Bison file on how it is currently
handled. I know that the two of us have a different meaning about this
topic but in case we extend access modifiers inconsistency grows.
var class ?!?
var function ?!?
var const ?!?
var static ?!?
>> 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.
>
I did not say that a userland developer should care I only stated that
it is one difference between a constant and a final property. ;)
>> - 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.
>
This thread is meant to find out where, how, when support is needed and
you are absolutely right that *__wakeup* needs support too. I am sure we
overlooked others yet. I did not claim to cover all edge cases. ;)
> 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.
>
That is exactly the point of it. Limiting interaction, limiting sources
of bugs. Just read why others want to have them instead of only taking
my word (and bad examples) for it.
>> 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.
>
It is an example to illustrate the functionality and not meant to be a
blueprint for all userland implementations that are yet to be written
till the end of time. It is contrived, no argument there.
>> 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?
>
Because you want to let child classes read from the property without
calling methods while making sure that they cannot change it in any way
(also called *readonly* in C#). This is particularly important in case
of object getters because a child class cannot trust the parent class
that an object retrieved from that getter is always the same instance.
This is why it is recommended to assign the result of such a call in a
method in various highly regarded literature (e.g. Steve McConnell Code
Complete comes to my mind).
With a *final val* property the child can trust the parent again. I know
that the situation is often different in PHP because the source is
always readily available. However, an API user should not need to dig
into the source code, an API user should be able to understand, use, and
trust other code simply through peeking at definitions and signatures.
Before you start, I am not claiming that this is always possible nor
that this is always desired, always needs to be like that, or anything
else. It is just something that is nice to achieve and it allows control
over what is going to happen at runtime and how people will be able to
interact with code that was written by you for them.
>> 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.
>
Public properties are available yet and used heavily in many projects to
create shitty anemic domain model for, you guessed it, performance
reasons. Providing a *final* keyword will not change that. Larry just
brought up the discussion regarding properties in interfaces, that's it
and nothing more.
>> 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 know that it might look like that but I still think that its usage is
ambiguous and inconsistent and all explanation attempts failed in the
old thread, in the RFC, and they will fail here. I do not know any other
way in that I could explain it to you so that you agree. However, I do
not know of I have to be that person who does that. It's fine for me if
you are against it or me. :)
>> 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.
>
Really? You should look at *final*, *val*, and *var* -- what are we
discussing here?
https://en.wikipedia.org/wiki/Final_%28Java%29
http://www.scala-lang.org/files/archive/spec/2.11/04-basic-declarations-and-definitions.html
http://stackoverflow.com/a/1327549/1251219
>> 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.
>
I said so and it was only an example. However, people are actually
trying (pthreads? anyone?) to bring this to PHP so never say never. ;)
>> (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.
>
You gain a shitload of DRY in userland. This is more than worthwhile.
You might react allergic towards syntactic sugar but it can be extremely
nice. But let's not get off-topic any further here (feel free to open
separate threads or resurrect the old one, I will reply).
--
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
