> In a multi-user system, any of these values could be different from
> one moment to the next.
>
> class Account{
> public property $AvailableBalance{
> get{
> return $this->CreditLimit - ($this->AccountBalance - $this->OnOrder);
> }
> }
> }
>
> This hides the mechanics away and tells any user that the account for
> this order has a realtime $CreditLimit, $AccountBalance, $OnOrder and
> an accurate $AvailableBalance. At the beginning and end of the order
> entry and maybe as each line is being entered, the AvailableBalance is
> accessed to see if it the current order can be met financially.
>
> The Account's properties are all read-only in this scenario (I'd have
> 2 Account classes, one for the Sales Ledger and a subclass for
> everywhere else. The ability to essentially remove the setter() in a
> subclass would turn a read/write property into a readonly property).
>
>
> So, based upon this fairly simple scenario, isset() would clearly
> alter the value of the account's properties if it had to call the
> getter()s.
I am not sure I follow, your example is complex to read and understand.
Loading the value of a property from a cache, or from a DB is fine,
although I see no benefit of doing it multiple times in the same page
load.
Besides, I think you mis-interpreted what I was saying. Please read again:
> The major issue I see here, is that a property should not be generating a
> value in an unpredictable way. In the example above, you indicate that
> the value could change just by calling the get method. While it is
> possible to write a property that does such a thing, this is completely
> incorrect and should not be actively supported by the language in any way.
> The value of a property (as viewed from the outside of the class) should
> never, ever change solely by a call to a getter method.
Specifically the part "a property should not be generating a value in an
unpredictable way." is what I was talking about. I think you took things
I wrote after that out of context. Changing the value that comes out a
property dynamically is fine, that is what they are for, however, it
should be predictable. A random value is not predictable, and should not
be in a getter.
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.
If you are loading a value from a database several times on the same page
load, it could be modified by some other process, and therefore that is
not very predictable. That should likely be a regular method
(CheckDBValue() or some such).
> You say "While it is possible to write a property that does such a
> thing, this is completely incorrect and should not be actively
> supported by the language in any way.".
>
> How are you going to stop me from writing code that DOES generate a
> new and appropriate value in response to a getter() request.
First, as noted above, this was taken out of context. Secondly, I never
said it should be prevented, but rather not supported. Those are very
different concepts.
> Surely that's the exact job of a getter()? To generate and supply a
> potentially new and accurate value. Not to supply some pre-hashed
> value which is accessible via __get() or by directly accessing a
> public variable (as seen in the EmployeeRecord on the MSDN link you
> gave - completely pointless).
Yes, that is one of the many jobs as a getter.
Just for the record, passing a value purely through a property without
changing it is far from pointless. First of all, it allows you to
independently create get or set methods, creating implicit readonly or
writeonly properties. By defining a property you can also set each
get/set methods visibility separately, or set either one final or
abstract.
In the case of creating a property that does not do any of this special
functionality, and just passes through a value, there are still arguments
for it. For one, it creates code uniformity. If 90% of the rest of a
classes public members are properties, then converting the last few public
variables to properties makes sense and is easier to read. Additionally,
if you define all public members as properties right off the bat, it is
easy to add additional functionality and validation checks as you go,
instead of stopping to convert the member to a property. These scenarios
are definitely supported in C#. For example, in more recent versions of
C#, you can now create a property like this:
public string MyString { get; set }
That right there, when compiled, is the exact same thing as this:
public class MyClass
{
private string someString;
public string MyString
{
get { return someString; }
set { someString = value; }
}
}
So as you can see, this scenario is heavily supported in C#, and is
considered good practice. Creating all public members as properties gives
you the most flexibility when creating classes and maintaining them in the
future.
> The response to isset/unset can only sensibly be handed by the
> designer of the property. Either as additional isset()/unset()
> functions in the property, or as a flag to the get()/set() functions
I disagree, isset/unset should have a default functionality and you should
not be required to implement them unless you have a special reason to do
so. Their definitions would be the exact same code 99% of the time
anyway, so it would only provide to be an annoyance to have to implement
them every time.
- Dennis
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
