On 5 December 2010 16:47, <presid...@basnetworks.net> wrote: > If I have an object called "PiggyBank", with the property "dollars" set to > 5, "dimes" set to 4 and "nickles" set to 1, then I get the contents of the > property "Total", I can predict it will give me the value 5.45. That is > what properties are really for.
To me, the "balance" on my piggy bank is a readonly, dynamic attribute/property. OK. Piggy bank is too small an entity. My kids' piggy banks have only 1 user per bank. The balance changes rarely 'cause they don't do a lot of housework. Yet. But for a larger entity, something with many people altering data via an "instrument of change" (a term I got from Sage Accounting a long time ago), then the "balance" on an account will change in unknown ways. And a synthetic property like "AvailableBalance" will certainly look like a random value, whilst orders are taken during the day and invoices raised and payments allocated. All in real time. A real world process. What I'm confused by is what you would consider a property? Why does predictability matter? Not all properties of an entity are predictable. My kids have an attribute of "mood". They sure as hell aren't predictable. If you have a clock object, the "time" is a readonly, dynamic property/attribute of a clock. Makes sense? You would want $clock->time as a property. Not $clock->getTime(). Well. OK. You _COULD_ and it would solve all the issues you have with dynamic, readonlys, but "time" is a property. What would you expect to be the natural behaviour of unset($clock->time); ? If I have to call getTime(), then I've just got setters/getters (__magic will do). Suddenly time is no longer a property of a clock. I can see we have very different opinions about the implementation and the possible use of properties. I'm quite happy with that. Either way, I think the basic proposal is very good. I've always wanted setters/getters in PHP specifically to implement readonly/writeonly attributes when I went from Delphi to PHP. The concept of grouping these together into a "property" (like C#), rather than having actual set and get methods (like Delphi) certainly does keep things together. I think being able to call the getter/setter as part of fluid interface would be useful. For each property, there would be getxxx, setxxxx, issetxxxx, unsetxxxx. That may look useful and I think for those that build classes like ORM systems, then probably of no issue and would be a major feature. But maybe too much for others not using that level of technology. As you can see, I'm not happy with having to keep with a "method" to update what I would consider a "property" (semantics and all that). I'm not happy with isset() calling the getter. But I'll adapt. I don't have the core knowledge or experience to argue much beyond what I've already said. The only thing I can think of though is __get can return a seemingly random value for an undefined property. In keeping with that, why couldn't a real property? In PHP's terms (not C#), what's the difference? Richard. -- Richard Quadling Twitter : EE : Zend @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
