Hi! > var class ?!? > var function ?!? > var const ?!? > var static ?!?
Ah, of course not. "var" is for vars. > 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. ;) This is not a difference that is important. > 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. ;) Part of my point is that covering the edges would be hard, because you are trying to introduce something that is not aligned with how the language is (or was) supposed to work, and thus require a lot of special cases. This is a sure recipe for trouble - once you rely on special-casing, you are guaranteed to forget some. KISS was not proclaimed a principle just because people are lazy and avoid work. > 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. But it's not limiting - you can not even refactor methods, so you'd have to copy-paste same code in several methods, with all bugs that follow. And of course you'd frequently forget to account for all places where magic should happen and get objects behaving in weird ways. This does not sound good. I can see a case between splitting read and write on class boundary - internal implementation can write, but outside can only read. In fact, this pattern is already widely implemented. I can see why you may want to get rid of this pattern of having interface/getter and instead have a pattern of public variables - but for this you'd need property interfaces first, and even then it would be unclear - how exactly the interface would specify readonly variable? Would you be allowed to extend it with r/w variable (I can give you equally sound arguments for "yes" and "no" here, depending on use case)? With getters/setters, the answer is clear - yes, you can extend it with setters, but if your invariant relies on immutability, you'd be violating LSP. With properties, not clear. It also seems to me like the main reason to do this is to exactly mimick behavior of "final" properties in Java - which is not a very worthy goal by itself. > 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. The problem is not that it's contrived, the problem is that it shows not why you need it but rather why you don't need it :) You are welcome to provide better example/use case, of course, but so far it looks to me like protected/getter works just fine. At the cost of a function call, of course, but see above why it may be preferable. > 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 You can always have private/protected as boundary instead of protected/public, that doesn't change much. Saving a function call looks like premature optimization here. > of object getters because a child class cannot trust the parent class > that an object retrieved from that getter is always the same instance. Not sure what you mean here. If the API allows to return different instances, then you get different instances. What's the problem here? > With a *final val* property the child can trust the parent again. I know This looks like wrong design approach - you are trying to put knowledge on the client that does not belong there - such as how many instances of value object exist and how they are managed. For value objects this looks wrong - if it's a value, it shouldn't matter which instance of it you are getting. If it's a mutable stateful object and not a value object, it's worse - you can't then know who messed with that object before and what is there now, so final doesn't help much. > 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 Ambiguous between what and what? If you see "var $foo", which two options you can not distinguish? How it is inconsistent? I think we need to stop using "inconsistent" when that is meant is "I do not like it". "var" is perfectly consistent and means always the same thing. There's better named alternative for it, true, and you're free to use that if you like. That's it. > Really? You should look at *final*, *val*, and *var* -- what are we > discussing here? "final" in Java is used in a lot of senses. Some of them would make sense in PHP, some not. For some cases, "final" doesn't actually provide much value - e.g. assigning a mutable object to a final variable, since it does not guarantee you anything really except keeping reference. There are a lot of optimizations that final is targeted for in Java, but I'm not sure those same optimizations are even possible in PHP. May be worth exploring though. >> 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. Sorry, I don't see it so far. I.e. I believe you think it'd be amazing, but I'd rather see some example of how it would be amazing and not take your word on it. Use cases are very important in design, in fact until we've got good use cases we don't have good design. > You might react allergic towards syntactic sugar but it can be extremely Oh, I'm not. But this is way beyond simple sugar, this is a bucketload of concepts that never existed in PHP, and I'd like to see they work with what does exist in PHP and they actually make sense for PHP, not just copying something Java does word-for-word. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
