> 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.
Sure, the balance is updated all the time in the database or whatever external data source it is stored in. But you are only loading from that database a single time in a page load. If you are loading it more than once, as per the C# guidelines, you should be doing it in a method, in order to signify that it is a resource intensive operation (makes a call to the data store every time its accessed... that is too intensive for a property, at least as agreed by the C# folks). Besides, this is not a common scenario. For the most part, if people are loading from a datastore, they will only load the data once per page, then cache it within the object instance. > 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. Yes, you would want it as a property. It is very predictable, as it gives you the current time of the clock. Lets say you call $clock->addHours(1), when you call $clock->time, you can expect it to be an hour further forward. If the clock is currently running, you can expect it to be one second higher for every second that passes. If $clock->time is being loaded from a datastore once per second where it could get modified, that is not predictable. Instead you should have $clock->syncTimeFromDataStore() or some such. Once you call that method, you know $clock->time is going to be modified. > What would you expect to be the natural behaviour of unset($clock->time);? I would guess that it just would not do anything. Either that or throw a non-fatal error. The user would have to know that the property is readonly, which they can do by looking at the documentation or the class definition. I think you mention this in the interest of the interchangeability of properties and variables. I suppose we cannot have full 100% interchangeability if we still want separate visibility levels (public,protected,private) on the get/set, and the possibility of readonly/writeonly. I think that the interchangeability of the two would be like so: - A property can always be replaced with a variable, even if the new property has separate visibility levels (or final, abstract) on its get and set methods, and will continue to "work". - A variable can be replaced by a property and be guaranteed to "work" as long as the new property does not have separate visibility levels (or final, abstract) on its get and set methods. > 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? A property certainly could return a random value, and it is perfectly "valid" to do so. But as a guideline its not recommended. As a concept, properties and fields (public variables) are supposed to tell you something about the object instance. They are an "attribute" of the object. If they don't produce predictable results, than they cease to tell you about the object. You should always create a method if you are going to "generate" an unpredictable value. This is a convention that makes coding with the C# libraries a joy, because properties always work in a predictable manner, and you know they will never give you some wild value. - Dennis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
