I'm opening up several new threads to get discussion going on the
remaining being debated categories referenced in this 1.1 - 1.2
change spec:
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented/change-requests
Shadowing
v1.1 has properties shadow accessors, the suggestion is that
I'm opening up several new threads to get discussion going on the
remaining being debated categories referenced in this 1.1 - 1.2
change spec:
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented/change-requests
I'm opening up several new threads to get discussion going on the
remaining being debated categories referenced in this 1.1 - 1.2
change spec:
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented/change-requests
I'm opening up several new threads to get discussion going on the
remaining being debated categories referenced in this 1.1 - 1.2
change spec:
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented/change-requests
I'm opening up several new threads to get discussion going on the
remaining being debated categories referenced in this 1.1 - 1.2
change spec:
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented/change-requests
Is the only intended benefit behind this proposal the ability to seamlessly
extend a seemingly normal property as an accessor?
On Fri, Oct 26, 2012 at 3:43 AM, Clint Priest cpri...@zerocue.com wrote:
I'm opening up several new threads to get discussion going on the
remaining being debated
On 26-10-2012 12:37, Clint Priest wrote:
Some people are in favor of the internal functions being generated by an
accessor declaration should be invisible and non-callable directly.
Others are in favor of leaving them
On 10/26/12 6:37 AM, Clint Priest wrote:
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented/change-requests
Some people are in favor of the internal functions being generated by an
accessor
declaration should be
Hi!
Some people are in favor of the internal functions being generated by an
accessor declaration should be invisible and non-callable directly.
Others are in favor of leaving them visible and callable.
I think these types are not right. It has nothing to do with
internals/userland, it has
Hi!
v1.2 Proposes that this be inverted such that if there is an accessor
defined for a given property name, the accessor will always be used. The
accessor would be able to get/set/isset/unset the property with the same
name as the accessor. No direct access to the property would be
Hi!
/* Would be equivalent to this */
class TimePeriod {
public $date {
get() { return $this-date; }
set(DateTime $value) { $this-date = $value;}
}
}
I don't think this has a use case and this encourages mixing variables
with properties (which I'm not sure is
Le 08/10/2012 14:27, Amaury Bouchard a écrit :
My idea was to write attribute's visibility like
read_visiblity:write_visibility $attr;
public:protected $foo; // public reading, protected writing
public:private $bar; // public reading, private writing
protected:private $aaa; // protected
Hi!
1. If all cases can be tested for during compilation, prefer
compile failures.
Not likely. isset($foo-$bar) is completely opaque since we don't know
what $foo or $bar is.
2. Let the compilation occur and at runtime when a disallowed
action is attempted, emit a
*Extra shorthand declaration*
Allow extra short declaration of an accessor:
class TimePeriod {
public DateTime $date;
}
/* Would be equivalent to this */
class TimePeriod {
public $date {
get() {
I'm all for having the internal methods being totally normal magic
methods, for the reduced complexity reasons already mentioned.
I would also expect to be able to simply define such a magic method myself,
and have it behave in just the same way as when defining it using the
accessor declaration
Hi!
I just have one question: can we drop `public`? Default visibility in
We already had var, it didn't prove a good idea. PHP is explicit for a
reason, to be clear.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP
On Fri, Oct 26, 2012 at 4:14 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
Some people are in favor of the internal functions being generated by an
accessor declaration should be invisible and non-callable directly.
Others are in favor of leaving them visible and callable.
I think
Hi!
users control. Actually, both approaches are exactly the same, the
only difference is whether we additionally put the accessor function
into the method table or whether we do not.
They may be almost the same technically, but very different
conceptually. Your approach means we introduce
Hi!
an accessor setter method for a property $_state IF that method would
follow the __set$PROPNAME pattern. As a solution for that, I'd propose
naming the new magic methods with a so-far-not-taken common prefix: __prop
- i.e. name them __prop_get_xxx, __prop_set_xxx, and so on.
I think it'd
On Fri, Oct 26, 2012 at 10:34 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
users control. Actually, both approaches are exactly the same, the
only difference is whether we additionally put the accessor function
into the method table or whether we do not.
They may be almost the same
Hi!
Stas, if you define an accessor, how do you define it? Do you say
Either way, doesn't matter.
According to the current proposal at least you can write the first
code *and the first code only*. If you write the second code then you
That's where I think it is wrong. It would be much
On 26/09/12 04:02 PM, Alec Smecher wrote:
On 20/09/12 12:02 PM, Alec Smecher wrote:
It looks to me like a textbook use case of pg_query_params will
currently fail depending on what locale is being used. What Claude at
https://bugs.php.net/bug.php?id=46408#1334753071 and Lars here are
trying
22 matches
Mail list logo
