.
From: Benjamin Eberlei [mailto:kont...@beberlei.de]
Sent: Thursday, June 28, 2012 4:55 AM
To: Clint Priest
Cc: Stas Malyshev; internals@lists.php.net
Subject: Re: [PHP-DEV] RFC: Property get/set syntax
What is the state here with regard to merge into php-src?
On Sun, Apr 22, 2012 at 5:48 AM
with.
Hopefully I'll have that fixed up later this week.
From: Benjamin Eberlei [mailto:kont...@beberlei.de]
Sent: Thursday, June 28, 2012 4:55 AM
To: Clint Priest
Cc: Stas Malyshev; internals@lists.php.net
Subject: Re: [PHP-DEV] RFC: Property get/set syntax
What is the state here with regard to merge
@lists.php.net
Subject: Re: [PHP-DEV] RFC: Property get/set syntax
Hi!
empty() - Returns true for a property retrieved via __get() or via a
getter -- Any idea why this would be the case for __get()? Is this a
bug?
isset() calls __isset(), empty() calls __isset() and __get
Hi!
- Variables may be used as input to out/ref arguments. Properties
may not.
This will probably be true for properties too, in some cases. However,
it is in no way an advantage.
- Properties may throw exceptions - variables will never do that.
In PHP, properties can not throw exceptions
I've updated the RFC to include details on adding isset/unset as well as
references, detailed below:
isset/unset:
class TimePeriod {
private $Seconds = 3600;
public $Hours {
get { return $this-Seconds / 3600; }
set { $this-Seconds = $value; }
isset { return
Clint,
Very nice job overall! Looking quite good.
Alternatively we could throw an error to a call on isset and/or unset
against a property which didn't define an implementation.
I don't care for that concept much. All it's doing is trading one set
of boilerplate for another. I'd prefer
Hi!
would it be possible to add a second shorthand syntax to the complete
automatic implementation?
Examples:
class TimePeriod
{
public $Hours {};
public property $Hours;
public $Hours {property};
}
That could save quite some typing.
Overall, i really like it.
On Tue, Apr 24,
Clint,
Additionally, one more comment related to the read-only and
write-only. I noticed that you're using E_ERROR for improper access.
Obviously you don't want this to be a warning, as the execution
shouldn't continue because that would be undefined. However, what
about setting it to
Hi!
would it be possible to add a second shorthand syntax to the complete
automatic implementation?
Examples:
class TimePeriod
{
public $Hours {};
public property $Hours;
public $Hours {property};
}
How it is different from just public $Hours and why one would need this?
Hi!
public $dataArray {
get { return $this-_dataArray; }
This is not correct. Please read:
http://php.net/manual/en/language.references.return.php
These would also include automatic implementations which call the
respective functions on the backing field. I could see only allowing
Hi!
These would also include automatic implementations which call the
respective functions on the backing field. I could see only allowing
isset/unset automatic implementations if get/set were also specified
as automatic implementations.
Another thing about that. The automatic
.
-Original Message-
From: Stas Malyshev [mailto:smalys...@sugarcrm.com]
Sent: Tuesday, April 24, 2012 12:34 PM
To: Clint Priest
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] RFC: Property get/set syntax (added isset/unset and
references)
Hi!
These would also include automatic
code at a later time.
This suggestion below shortens the syntax even further.
-Original Message-
From: Stas Malyshev [mailto:smalys...@sugarcrm.com]
Sent: Tuesday, April 24, 2012 12:11 PM
To: Benjamin Eberlei
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] RFC: Property get/set syntax
however as Derick mentions on his post about E_RECOVERABLE_ERROR.
-Original Message-
From: Anthony Ferrara [mailto:ircmax...@gmail.com]
Sent: Tuesday, April 24, 2012 10:40 AM
To: Clint Priest
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] RFC: Property get/set syntax (added isset
-Original Message-
From: patrick.alla...@gmail.com [mailto:patrick.alla...@gmail.com] On Behalf Of
Patrick ALLAERT
Sent: Friday, April 20, 2012 5:36 AM
To: Stas Malyshev
Cc: Clint M Priest; internals@lists.php.net
Subject: Re: [PHP-DEV] RFC: Property get/set syntax
2012/4/20 Stas Malyshev smalys
How these would work with isset - what !empty($this-Hours) return? What
would happen if you do unset($this-Hours)? What happens if you do
$this-Hours++ or sort($this-Hours) (assuming $Hours is an array)?
These things need to be defined in the RFC too.
So I've just tested these things and
Hi!
empty() - Returns true for a property retrieved via __get() or via a
getter -- Any idea why this would be the case for __get()? Is this a
bug?
isset() calls __isset(), empty() calls __isset() and __get(). I'm not
sure what exactly you consider to be a bug.
unset() - Would unset a
-Original Message-
From: Stas Malyshev [mailto:smalys...@sugarcrm.com]
Sent: Saturday, April 21, 2012 10:33 PM
To: Clint M Priest
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] RFC: Property get/set syntax
Hi!
empty() - Returns true for a property retrieved via __get
Hi!
If there is no other discussion for this, I'd like to move this to the voting
phase, any objects?
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
Sorry, I didn't have time to look into it yet (yes I know it was around
for a long time...) in detail. From the quick glance I
Hi,
Are the dashes acceptable or undesirable?
I think without dashes it is more in line with other keywords, like
instanceof or insteadof.
Because keywords are not case sensitive, one who likes them to be more readable
could write them camelCased, for example readOnly, or writeOnly.
--
2012/4/20 Stas Malyshev smalys...@sugarcrm.com:
How these would work with isset - what !empty($this-Hours) return? What
would happen if you do unset($this-Hours)? What happens if you do
$this-Hours++ or sort($this-Hours) (assuming $Hours is an array)?
These things need to be defined in the RFC
On 2012-04-20, Christoph Hochstrasser christoph.hochstras...@gmail.com wrote:
Hi,
Are the dashes acceptable or undesirable?
I think without dashes it is more in line with other keywords, like
instanceof or insteadof.
Because keywords are not case sensitive, one who likes them to be more
The only open comments I have on this project is the read-only and
write-only keywords.
Are the dashes acceptable or undesirable?
write-only was not in the original RFC but made sense to have the alternate to
read-only, any objections?
If there is no other discussion for this, I'd like to
23 matches
Mail list logo
