efully 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 i
playing around 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
int 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() or via a
> > > getter -- Any idea why this would be the case for __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 excepti
in an unstable state
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:
rs to indicate
their intention to make them execute 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.n
that interface.
-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
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 implement
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 allowin
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
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 E_RECOVERA
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, 2012
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
> -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() - Retu
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 te
> 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
as parent::?
-Clint
-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
201
On 2012-04-20, Christoph Hochstrasser 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
> readable could writ
2012/4/20 Stas Malyshev :
> 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.
My sugge
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
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
21 matches
Mail list logo
