Re: [PHP-DEV] PR 186: external protocols and locale independent string conversion

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 and Lars here are trying

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

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 sim

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

On Fri, Oct 26, 2012 at 10:34 PM, Stas Malyshev 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 technically, b

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

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 i

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

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

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

On Fri, Oct 26, 2012 at 4:14 PM, Stas Malyshev 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 these types are

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Extra shorthand 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 Run

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

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

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Extra shorthand declaration

> > *Extra shorthand declaration* > > Allow extra short declaration of an accessor: > > class TimePeriod { > public DateTime $date; > } > > /* Would be equivalent to this */ > > class TimePeriod { > public $date { >

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : isset / unset "failable"

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 wa

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

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; // protecte

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Extra shorthand declaration

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 no

Re: [PHP-DEV] [RFC] Property Accessors 1.2 : Shadowing

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 all

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

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 ha

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

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 i

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor MethodVisibility / Callability

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 visibl

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Extra shorthand declaration

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 wrote: > I'm opening up several new threads to get discussion going on the > remaining "being debated" categories reference

[PHP-DEV] [RFC] Property Accessors v1.2 : Extra shorthand declaration

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

[PHP-DEV] [RFC] Property Accessors v1.2 : Interfaces

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

[PHP-DEV] [RFC] Property Accessors v1.2 : isset / unset "failable"

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

[PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

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

[PHP-DEV] [RFC] Property Accessors 1.2 : Shadowing

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