[RFC] Propety Accessors v1.1 View as Markdown

At this point, the last two weeks of deliberations on this RFC have pushed its release back quite a long ways. I don't know when 5.5 is due out but if it's within the next 6 months (and I'm the only one working on the code) then it will probably not be happening. Due to the dramatic changes that have been talked about, I may just scrap the fork and start over, since I've learned a lot about php-core since starting this a year ago.

-----Original Message-----
From: Stas Malyshev [mailto:smalyshev@sugarcrm.com]
Sent: Tuesday, October 16, 2012 4:27 AM
To: Paul Dragoonis
Cc: Clint Priest; internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1

Hi!

What remains on your TODO list for this functionality?
When are you planning to run an RFC vote on this?

I think this would be a valuable addition to PHP 5.5.

I think we shouldn't rush with votes on this until all fine details aren't hashed out. This is a huge feature - one of the biggest ones
recently, and has a lot of implications for various scenarios. Property access is what virtually every script in existence does, and
doing changes there have implications that touch every corner of the engine.

I think Clint is doing a great job with this RFC, but we need to carefully work through all the corners and side cases and relationships
with all other features before we can declare it's ready for the prime time. Exactly because it is such a big deal it needs to be refined
and polished.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

Hi!

What remains on your TODO list for this functionality?
When are you planning to run an RFC vote on this?

I think this would be a valuable addition to PHP 5.5.

I think we shouldn't rush with votes on this until all fine details
aren't hashed out. This is a huge feature - one of the biggest ones
recently,

Exactly because it is such a big deal it needs to be refined and
polished.

Amen.

Stas Malyshev wrote:

What remains on your TODO list for this functionality?
When are you planning to run an RFC vote on this?

I think this would be a valuable addition to PHP 5.5.
I think we shouldn't rush with votes on this until all fine details
aren't hashed out. This is ahuge feature - one of the biggest ones
recently, and has a lot of implications for various scenarios. Property
access is what virtually every script in existence does, and doing
changes there have implications that touch every corner of the engine.

I think Clint is doing a great job with this RFC, but we need to
carefully work through all the corners and side cases and relationships
with all other features before we can declare it's ready for the prime
time. Exactly because it is such a big deal it needs to be refined and
polished.

But a vote NOT to include it should still be one of the options!

The more edge cases I see on this discussion, the more I am convinced that this
is simply not right for PHP ... it's not needed and only adds unnecessary bloat.
The more the functionality of PHP gets buried in 'magic code' that can't even be
debugged properly or viewed the less useful PHP becomes.

I'm sorry if people are spending a lot of time trying to make something work,
but that is their choice, and should not be a reason to include something.
I still don't see how this improves anything when all we need to be doing is
managing the existing variables, arrays and objects stored in the object. __get
and __set aren't needed either but that is another matter. Does anybody actually
use them, or are they waiting for the 'better alternative'?

Is there any real reason not simply to be using $obj->var ? It is the fastest
way of doing it anyway ...

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Hi Clint,

In order to achieve read-only and write-only, we could do something
similar to this:

/* Explicitly read-only, sub-classes may redefine the getter but may
not define a setter */
public $Hours {
get() { ... }
final private set() {}
}

This would make the additional keyword superfluous. It's very similar
to what is currently done in Singleton classes that usually have
private constructors.

Second, I'd like to throw in the idea of array accessors. I mentioned
this before, but did not get any response.

public $Addresses {
offsetSet($offset, $value) { ... }
offsetGet() { ... }
offsetUnset($offset) { ... }
offsetExists($offset) { ... }
}

The reasoning for this feature is that in object-oriented design you
have to process logic when establishing bidirectional associations
between objects. For example, adding an Address to a Contact instance
would require Address::$Contact to be set as well if the association
is bidirectional.

public $Addresses {
offsetSet($offset, $address) {
$address->Contact = $this;
}
}

$contact->Addresses[] = new Address();

What do you think about supporting this?

Cheers,
Bernhard

Wow, I'm surprised by all the talk about this RFC this time around. I
posted this numerous times in the past trying to elicit feedback and got
little to none, so I took the time to write it as I thought it should be
written. Some of these things will take considerable effort to
fix/correct/change.

Sometimes things get overlooked. Lots of suggestions make their way to
the list, usually by people who have no way to implement the feature
and they disappear as quickly as they are suggested. Be happy you ARE
getting feedback now. The fact people now see this as something that
may be implemented as it is (in a way they don't necessarily like) is
prompting them to speak up about their concerns.

What concerns me with the current implementation is that it leaks many
implementation details, in particular the fact that the accessors are
implemented as real __getXYZ methods and automatic implementations also
use real $__XYZ properties.

I don't particularly see this as a problem (the ability to use it as a
getter or call it as a function), but see my comments at the end. I also
don’t particularly see the point of auto implemented getters/setters (
public $h { get; set; } )

For me the problem is simply that you can call the accessor functions
directly. I don't like it.

I don't like the fact that accessors and their associated properties
are implemented as direct (yet slightly obfuscated/hidden) elements of
the containing class. It's unintuitive (I'd even go as far as saying
confusing)

A property should be a property, not a collection of hidden methods
and variables. If it needs to be seen whether a property implements
accessors, this should be done through reflection.

3 - Can directly access $__automaticProperty and even unset it (causing

notices in the internal code)

I'm not even sure that automatic backing fields are even desired

See above I guess, I agree that these "hidden" properties should not
exist in the first place.

I think it would
be better to cleanly separate out the accessor implementation. It might
require more code now, but will be better in the long run.

All three of these issues, could be addressed I believe by not having the
functions and/or properties a part of the ordinary HashTables, or to have
flags set on them. I believe there is already a SHADOW flag type defined
which may be able to be used for this type of functionality.

Nikita do you have any other proposals for how this should be
addressed? I think most of my concerns with this revolve around the
implementation not being cleanly separated as you put it. I believe
that setters/getters would be a tremendously powerful and useful
addition to the language, just not quite like this, so lets here your
proposal please :)

public $property {
set { $this->property = ($this->property*2)+$value } get; }

How do I reference the property being set from within the function? The
way I have done it in the example will cause recursion? How can I assign to
"self"?

Generally speaking, I don't know why you would use an automatic backing
getter with a separate setter, but if you wanted to do that, at present you
would access the automatic backing field by $this->__property.

Kind of confusing. We have to think of the users who just want to pick
this up and run with it. You can't say "I don't know why you would",
because people will do strange things, and you have to make it so that
the behaviour is predictable, and intuitive.

The above will not cause recursion, it is protected from recursion by the
same mechanism that __get() and __set() are protected.

Good, thanks. I didn't get to test it since I was on a bus at the time :)

In fact, the above
code would set an actual property named $property on the object which would
then side-step the accessor entirely (true properties take precedence over
accessors, though they may only be "set" from within the setter of the
accessor. This may be a bit confusing, but I specifically wrote it this way
for the purpose of lazy-loading.

Yep, confusing!

The first access of the $objList property getter would create the object and
attempt to set its-self which would be passed to the setter, the setter (now
guarded) will directly set the property on the object, further calls to
$objList would retrieve the already created object (bypassing the accessor).
To get out of that situation, you would simply unset($objList) and the
accessor would take over again.

Also confusing. (Think of the users!)

I think Leigh brings up some important flaws to in the current RFC. What
Leigh is asking for does not appear to be possible, and in my opinion, it
should be.

I'm really not quite clear on what Leigh was going for with the code she
indicated, I think she was trying to demonstrate infinite recursion which is
not possible due to guards.

She? Only when I go shoe shopping with Nikita at the weekends...

Actually the recursion thing was just a query I hadn't tested, and you
have answered. The other question I asked was "How do you set the
default value of the property with the accessor syntax?"

I think there is some wide-spread confusion over what an accessor is. An
accessor does not store its own value, there is no “memory space” allocated
for an accessor unless you use the automatic implementation ( public $h {
get; set; } ) but if you’re going to do that, you may as well just reduce it
to ( private $__h ) which is all the previous “accessor” would have done for
you.

Accessors, in my own use, are nearly always used for convenience aliases
with conversions ( $Hours calculated based on a real stored $Seconds value)
or as an alias to access a value from another class, they are generally not
used to simply store or retrieve values, that’s what a property is for, an
accessor is for executing code with the syntactic sugar of making it seem
like it’s a variable.

In my opinion

public $property; // This is a property

public $property { // This is still a property
set { ... }
}

I don't see accessors tied to the property as ways of simply setting
some other value (in your example, setting $seconds via $hours). I
have a feeling a lot of people will not be using these simply for
conversions, they will also be using them for validation and
sanitising. You already saw Niki throwing an Exception inside an
accessor.

try {
$user->username = $rawData
} catch (InvalidUsernameException $e) {
...
}

They will expect the $username property to contain the data, not
$__username, and not having to implement $saneUsername as a second
property to store it in.

I'm not even sure that automatic backing fields are even desired, I never
felt the need to have them in C# and the only reason they were included is
because they were a part of Dennis's original proposal. Eliminating them
would eliminate this as an issue.

I just did a bit of research regarding this topic and I have found the
following reasons why automatic properties exist in C#:

1. Changing a field to a property breaks the binary interface, so all
   code using the library has to be recompiled. If you are using an
   automatic property you can safely add additional behavior for it
   later.
2. Properties support data binding, whereas fields do not.
3. There are attributes that work for properties, but don't work for fields.
4. Reflection for fields and properties works differently, so changing
   a field to a property is a BC break.

I guess that #1 is the most important one (you don't want to break the
interface) and it obviously does not apply to PHP. Points #2 and #3
also don't apply as PHP has neither data binding not attributes. #4
also doesn't seem to apply because ReflectionPropertyAccessor defines
all the methods that ReflectionProperty defines, so changing
field->property should be okay there too.

From that I would conclude that the automatic properties are really
not needed in PHP. I think they will only cause confusion as to when
one should use public $name; and when one should use public $name { get; set; };.

The only thing I'm not sure about is how read-only / write-only
properties rely on automatic properties with your current
implementation. If the automatic properties aren't needed there
either, then I think they can be safely removed.

Nikita

Great arguments for, anyone against this being the new way? If not then I’ll begin work on this change as well. I would like to keep this discussion going so that at the end of this two week discussion period I can submit it for voting.

Jazzer, your points make a lot of sense in terms of making it clear that they are all functions, I’m all game. If it’s not difficult I may just make it compatible in both ways (auto-define $value) if parenthesized option is not specified. Flexibility is at the heart of php.

-Clint

From: Jazzer Dane [mailto:tbprogrammer@gmail.com]
Sent: Monday, October 08, 2012 10:08 PM
To: Clint Priest
Cc: internals@lists.php.net; Aaron Holmes; Benjamin Eberlei
Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1

While I understand your concern with set being the only keyword using (), and even agree it's a bit problematic, I see a big problem with using $value.

Even if $value internally makes sense due to something along the lines of __setHours($value) {} being equal to set {}, I think using $value without it ever being defined in the developer's code is not at all a good idea.
If I see $value in the code, I'll logically look for where it was defined, and when I don't see it anywhere else in the code, things are going to very quickly get confusing.
Our best option to combat this confusion is, in my eyes, putting a note in the documentation. That's not enough.

A similar alternative to using $value that I'd argue would be much more sensible would be to, as Denis mentioned, use either a magic constant or a superglobal.

As I mentioned previously, I would rather go with the set($value) {} syntax.

Now, back to the part where I agree with you - the inconsistency wherein set has () that denote it is a method but get, isset, and unset do not. I see this inconsistency as something problematic enough to warrant a solution.

We could go with the following:
public $Hours {
get() { ... }
set($value) { ... }
isset() { ... }
unset() { ... }
}

Yes, we now have a little bit more meat on the syntax, but in this case, I don't think that it's all that bad. Here's two reasons why:

1. Adding parenthesis denotes that they are all functions - which they are! If anything, adding parenthesis to all of them makes the implementation more sensible.
2. It's only two more characters per function. On top of that, in my opinion, this syntax is not "ugly". In fact, as I just mentioned - this implementation is arguably more consistent with the rest of PHP.

Seems a fair amount of people would like it with a definable parameter name, though the original RFC I based mine off of is more than 4 years old (mine is over a year old already).

The $value is precisely chosen because it is exactly the way C# operates and the original author thought to keep it the same as another well-known language (why re-invent new syntax for no reason).

That being said, javascript does indeed allow it, my concern then would be would we have the parameterized syntax only for set() and not get, isset or unset?

If we do have them for all of them, it's a lot of extra characters with no real need.

I definitely favor set($value) over a magic $Hours for the $Hours property, but I personally see no problem with the $value, it's not magic it's a locally defined variable.

Internally, this:
public $Hours {
get { ... }
set { ... }
}

Is implemented as standard functions, while they are hidden through reflection, these functions exist (as a result of the above example):

public __getHours() { ... }
public __setHours($value) { ... }

Lastly, with regards to JavaScript style getters/setters, I don't think I've ever cared what the variable name was, I typically just do something like:

set blah(x) { ... } <-- x is fairly irrelevant and similarly the use of $value is fairly irrelevant. Thoughts?

-----Original Message-----
From: Jazzer Dane [mailto:tbprogrammer@gmail.commailto:tbprogrammer@gmail.com]
Sent: Monday, October 08, 2012 5:32 PM
To: Benjamin Eberlei
Cc: Aaron Holmes; internals@lists.php.netmailto:internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1

I agree.
It's more consistent than the $Hours solution and we don't have to add another superglobal or magic constant, which is quite nice. The
typehinting is a big plus as well.

On Mon, Oct 8, 2012 at 3:26 PM, Benjamin Eberlei <kontakt@beberlei.demailto:kontakt@beberlei.de>wrote:

The set() one is really nice with the typehints.

On Tue, Oct 9, 2012 at 12:19 AM, Aaron Holmes <aaron@aaronholmes.netmailto:aaron@aaronholmes.net>
wrote:

08.10.2012 15:52, Clint Priest пишет:

 public $Hours {
     get { return $this->Seconds / 3600; }
     set { $this->Seconds = $value; }
     isset<http://www.php.net/isset**>  { return isset<

http://www.php.net/isset**>($this->Seconds); }
unsethttp://www.php.net/unset** { unset<
http://www.php.net/unset**>($this->Seconds); }
}

Hi Clint,

I've noticed some magic variable '$value' is introduced. And except
for superglobals I guess there is no such thing in PHP, so it looks
bit puzzling to me. I'd suggest on of the following:

• setter resambles setter method, wich also allows typehinting
  public $Hours {
  set ($value) { $this->Seconds = $value * 3600; }
  }

  public $Hours {
  set (DateTime $dateTime) { $this->Seconds =
  $dateTime->getTimestamp(); }
  }

This seems like the cleanest method, in my opinion. Javascript
does
this
for object prototypes:
http://ejohn.org/blog/**javascript-getters-and-**setters/<;
http://ejohn.org/blog/javascript-getters-and-setters/>;

What do you think?

Thanks
Denis

--
To unsubscribe,
visit: http://www.php.net/unsub.php

I personally like the idea by Denis Portnov with the magic constant VALUE which goes along with other magic constants documented here http://www.php.net/manual/en/language.constants.predefined.php

But the advantage of the "type hinting" in the setter when we use "set($value)" should be weighted stronger. This is a great plus!
I would vote for Jazzer's

public $Hours {
get() { ... }
set($value) { ... }
isset() { ... }
unset() { ... }
}

Best regards
Christian Stoller

-----Original Message-----
From: Jazzer Dane [mailto:tbprogrammer@gmail.com]
Sent: Tuesday, October 09, 2012 5:08 AM
To: Clint Priest
Cc: internals@lists.php.net; Aaron Holmes; Benjamin Eberlei
Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1

While I understand your concern with set being the only keyword using (),
and even agree it's a bit problematic, I see a big problem with using
$value.

Even if $value internally makes sense due to something along the lines of *
__setHours($value)* {} being equal to set {}, I think using $value
without it ever being defined in the developer's code is not at all a good
idea.
If I see $value in the code, I'll logically look for where it was defined,
and when I don't see it anywhere else in the code, things are going to very
quickly get confusing.
Our best option to combat this confusion is, in my eyes, putting a note in
the documentation. That's not enough.

A similar alternative to using $value that I'd argue would be much more
sensible would be to, as Denis mentioned, use either a magic constant or a
superglobal.

As I mentioned previously, I would rather go with the set($value) {} syntax.

Now, back to the part where I agree with you - the inconsistency wherein
set has () that denote it is a method but get, isset, and unset do not. I
see this inconsistency as something problematic enough to warrant a
solution.

We could go with the following:
public $Hours {
get() { ... }
set($value) { ... }
isset() { ... }
unset() { ... }
}

Yes, we now have a little bit more meat on the syntax, but in this case, I
don't think that it's all that bad. Here's two reasons why:

1. Adding parenthesis denotes that they are all functions - which they are!
   If anything, adding parenthesis to all of them makes the implementation *
   more* sensible.
2. It's only two more characters per function. On top of that, in my
   opinion, this syntax is not "ugly". In fact, as I just mentioned - this
   implementation is arguably more consistent with the rest of PHP.

Seems a fair amount of people would like it with a definable parameter
name, though the original RFC I based mine off of is more than 4 years old
(mine is over a year old already).

The $value is precisely chosen because it is exactly the way C# operates
and the original author thought to keep it the same as another well-known
language (why re-invent new syntax for no reason).

That being said, javascript does indeed allow it, my concern then would be
would we have the parameterized syntax only for set() and not get, isset or
unset?

If we do have them for all of them, it's a lot of extra characters with no
real need.

I definitely favor set($value) over a magic $Hours for the $Hours
property, but I personally see no problem with the $value, it's not magic
it's a locally defined variable.

Internally, this:
public $Hours {
get { ... }
set { ... }
}

Is implemented as standard functions, while they are hidden through
reflection, these functions exist (as a result of the above example):

public __getHours() { ... }
public __setHours($value) { ... }

Lastly, with regards to JavaScript style getters/setters, I don't think
I've ever cared what the variable name was, I typically just do something
like:

set blah(x) { ... } <-- x is fairly irrelevant and similarly the use of
$value is fairly irrelevant. Thoughts?

-----Original Message-----
From: Jazzer Dane [mailto:tbprogrammer@gmail.com]
Sent: Monday, October 08, 2012 5:32 PM
To: Benjamin Eberlei
Cc: Aaron Holmes; internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1

I agree.
It's more consistent than the $Hours solution and we don't have to add
another superglobal or magic constant, which is quite nice. The
typehinting is a big plus as well.

On Mon, Oct 8, 2012 at 3:26 PM, Benjamin Eberlei <kontakt@beberlei.de
wrote:

The set() one is really nice with the typehints.

On Tue, Oct 9, 2012 at 12:19 AM, Aaron Holmes aaron@aaronholmes.net
wrote:

08.10.2012 15:52, Clint Priest пишет:

 public $Hours {
     get { return $this->Seconds / 3600; }
     set { $this->Seconds = $value; }
     isset<http://www.php.net/isset**>  { return isset<

http://www.php.net/isset**>($this->Seconds); }
unsethttp://www.php.net/unset** { unset<
http://www.php.net/unset**>($this->Seconds); }
}

Hi Clint,

I've noticed some magic variable '$value' is introduced. And except
for superglobals I guess there is no such thing in PHP, so it looks
bit puzzling to me. I'd suggest on of the following:

• setter resambles setter method, wich also allows typehinting
  public $Hours {
  set ($value) { $this->Seconds = $value * 3600; }
  }

  public $Hours {
  set (DateTime $dateTime) { $this->Seconds =
  $dateTime->getTimestamp(); }
  }

This seems like the cleanest method, in my opinion. Javascript
does
this
for object prototypes:
http://ejohn.org/blog/**javascript-getters-and-**setters/<;
http://ejohn.org/blog/javascript-getters-and-setters/>;

What do you think?

Thanks
Denis

--
To unsubscribe,
visit: http://www.php.net/unsub.php

Hi,

typehinting should definitely be available for this feature. But I have
another question. Why not go more consistent with the rest of the
language? I have mentioned this previously as the first proposal comes
up on the list. In my opinion the AS3 getter and setter
syntax(http://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7f30.html#WS5b3ccc516d4fbf351e63e3d118a9b90204-7fcb)
fits more into the language as the proposed one.

Here are my concerns:

• I do not like the extra indentation level and it's ugly to document
  (OK, this is a personal preference)
• It isn't possible to declare a private setter and a public getter, as
  it is possible with methods
• If we ever get return type hinting/checks then we needn't consider
  how the syntax has to look
• We must deal with two different syntaxes for the same thing, because
  both are methods
• IDE's, documentation tools, static analyses tools or similar tools
  have a huge effort to implement this syntax. With the method syntax it's
  only a small effort
• We have to create new rules about how the documentation for this
  syntax should look like

For me the following syntax seems more consistent with the rest of PHP:

public get hours() {}
public set hours(DateTime $dateTime) {}
public isset hours() {}
public unset hours() {}

Or:

public function get hours() {}
public function set hours(DateTime $dateTime) {}
public function isset hours() {}
public function unset hours() {}

Or:

public function get $hours() {}
public function set $hours(DateTime $dateTime) {}
public function isset $hours() {}
public function unset $hours() {}

Cheers,
Christian

Am 09.10.2012 05:08, schrieb Jazzer Dane:

While I understand your concern with set being the only keyword using
(),
and even agree it's a bit problematic, I see a big problem with using
$value.

Even if $value internally makes sense due to something along the
lines of *
__setHours($value)* {} being equal to set {}, I think using $value
without it ever being defined in the developer's code is not at all a
good
idea.
If I see $value in the code, I'll logically look for where it was
defined,
and when I don't see it anywhere else in the code, things are going
to very
quickly get confusing.
Our best option to combat this confusion is, in my eyes, putting a
note in
the documentation. That's not enough.

A similar alternative to using $value that I'd argue would be much
more
sensible would be to, as Denis mentioned, use either a magic constant
or a
superglobal.

As I mentioned previously, I would rather go with the set($value) {}
syntax.

Now, back to the part where I agree with you - the inconsistency
wherein
set has () that denote it is a method but get, isset, and unset do
not. I
see this inconsistency as something problematic enough to warrant a
solution.

We could go with the following:
public $Hours {
get() { ... }
set($value) { ... }
isset() { ... }
unset() { ... }
}

Yes, we now have a little bit more meat on the syntax, but in this
case, I
don't think that it's all that bad. Here's two reasons why:

1. Adding parenthesis denotes that they are all functions - which
   they are!
   If anything, adding parenthesis to all of them makes the
   implementation *
   more* sensible.
2. It's only two more characters per function. On top of that, in
   my
   opinion, this syntax is not "ugly". In fact, as I just mentioned -
   this
   implementation is arguably more consistent with the rest of PHP.

On Mon, Oct 8, 2012 at 6:10 PM, Clint Priest cpriest@zerocue.com
wrote:

Seems a fair amount of people would like it with a definable
parameter
name, though the original RFC I based mine off of is more than 4
years old
(mine is over a year old already).

The $value is precisely chosen because it is exactly the way C#
operates
and the original author thought to keep it the same as another
well-known
language (why re-invent new syntax for no reason).

That being said, javascript does indeed allow it, my concern then
would be
would we have the parameterized syntax only for set() and not get,
isset or
unset?

If we do have them for all of them, it's a lot of extra characters
with no
real need.

I definitely favor set($value) over a magic $Hours for the $Hours
property, but I personally see no problem with the $value, it's not
magic
it's a locally defined variable.

Internally, this:
public $Hours {
get { ... }
set { ... }
}

Is implemented as standard functions, while they are hidden through
reflection, these functions exist (as a result of the above
example):

public __getHours() { ... }
public __setHours($value) { ... }

Lastly, with regards to JavaScript style getters/setters, I don't
think
I've ever cared what the variable name was, I typically just do
something
like:

set blah(x) { ... } <-- x is fairly irrelevant and similarly the use
of
$value is fairly irrelevant. Thoughts?

-----Original Message-----
From: Jazzer Dane [mailto:tbprogrammer@gmail.com]
Sent: Monday, October 08, 2012 5:32 PM
To: Benjamin Eberlei
Cc: Aaron Holmes; internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1

I agree.
It's more consistent than the $Hours solution and we don't have to
add
another superglobal or magic constant, which is quite nice. The
typehinting is a big plus as well.

On Mon, Oct 8, 2012 at 3:26 PM, Benjamin Eberlei
<kontakt@beberlei.de
wrote:

The set() one is really nice with the typehints.

On Tue, Oct 9, 2012 at 12:19 AM, Aaron Holmes
aaron@aaronholmes.net
wrote:

08.10.2012 15:52, Clint Priest пишет:

 public $Hours {
     get { return $this->Seconds / 3600; }
     set { $this->Seconds = $value; }
     isset<http://www.php.net/isset**>  { return isset<

http://www.php.net/isset**>($this->Seconds); }
unsethttp://www.php.net/unset** { unset<
http://www.php.net/unset**>($this->Seconds); }
}

Hi Clint,

I've noticed some magic variable '$value' is introduced. And
except
for superglobals I guess there is no such thing in PHP, so it
looks
bit puzzling to me. I'd suggest on of the following:

• setter resambles setter method, wich also allows
  typehinting
  public $Hours {
  set ($value) { $this->Seconds = $value * 3600; }
  }

  public $Hours {
  set (DateTime $dateTime) { $this->Seconds =
  $dateTime->getTimestamp(); }
  }

This seems like the cleanest method, in my opinion.
Javascript
does
this
for object prototypes:
http://ejohn.org/blog/**javascript-getters-and-**setters/<;
http://ejohn.org/blog/javascript-getters-and-setters/>;

What do you think?

Thanks
Denis

--
To
unsubscribe,
visit: http://www.php.net/unsub.php