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
?
> -Original Message-
> From: David Muir [mailto:davidkm...@gmail.com]
> Sent: Tuesday, October 16, 2012 11:20 PM
> To: Clint Priest
> Cc: Stas Malyshev; Nikita Popov (nikita@gmail.com);
> internals@lists.php.net
> Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Access
On 16/10/12 22:34, Clint Priest wrote:
-Original Message-
From: Stas Malyshev [mailto:smalys...@sugarcrm.com]
Sent: Tuesday, October 16, 2012 6:06 AM
To: Clint Priest
Cc: Nikita Popov (nikita@gmail.com); internals@lists.php.net
Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property
My choice of words were misleading/incorrect. If you are programming to an
interface then the interface dictates what *will* work, if you attempt to use
an interface to do something that the interface has not declared is supported
then it may work or it may fail.
On Oct 16, 2012, at 7:43 AM, "
Hi!
> If you have a public property $a which internally can only deal with
> it being set to 2 or 3 and someone external to the class sets it to
> 4, your class either has to check that it's 2 or 3 and deal with the
> fact that it is now 4 or have indeterminate results when it is set to
> 4.
Most
> -Original Message-
> From: Stas Malyshev [mailto:smalys...@sugarcrm.com]
> Sent: Tuesday, October 16, 2012 6:06 AM
> To: Clint Priest
> Cc: Nikita Popov (nikita@gmail.com); internals@lists.php.net
> Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 :
Hi!
> that supports properties in interfaces. Again, not exhaustive either
> but there is one language that does support accessors in interfaces
> and that's C#.
So what C# does when mixing regular properties and accessorized properties?
> Think about it, if you allowed an outside caller of you
sugarcrm.com]
> Sent: Tuesday, October 16, 2012 4:37 AM
> To: Clint Priest
> Cc: Nikita Popov (nikita@gmail.com); internals@lists.php.net
> Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Interfaces
>
> Hi!
>
> > I think that accessors should be allowed w
Hi!
> I think that accessors should be allowed with interfaces because an
> interface really is a specification on how to communicate and while
> accessors do pass messages, properties do not.
"Communicate" is a loaded term. Property access is communication too,
but properties aren't defined in t
This discussion is opened in the dedicated thread. I used my proposal as an
example to illustrate my point of view, not to pollute this thread.
2012/10/16 Jazzer Dane
> I prefer the current syntax to your proposal because:
>
> 1) It is not at all obvious which side is which. Example:
> *prot
I prefer the current syntax to your proposal because:
1) It is not at all obvious which side is which. Example:
*protected:private
*Is protected* *for get? Or set? The average PHP developer will have no
idea. In fact, they likely won't know that they even correlate to get and
set.
2) Ther
2012/10/15 Clint Priest
> Also, your "should be valid" statement implies that you feel properties
> and accessors are the same and they are not, internally. When a class
> attempts to implement an interface a "function check" is done and since
> there is no __getXX() function defined it would fa
On 16/10/12 14:55, Jazzer Dane wrote:
I'm going to agree with David here. It is most sensible to either
allow properties AND accessors in interfaces, or don't allow either of
them. __get/__set is a different subject that I'd rather not dig into
while discussing this RFC.
I tossed in the __get
I'm going to agree with David here. It is most sensible to either allow
properties AND accessors in interfaces, or don't allow either of them.
__get/__set is a different subject that I'd rather not dig into while
discussing this RFC.
On Mon, Oct 15, 2012 at 8:43 PM, David Muir wrote:
> On 16/10/
On 16/10/12 13:37, Clint Priest wrote:
On Mon, Oct 15, 2012 at 6:02 PM, Clint Priest wrote:
> >Because fundamentally interfaces are designed to explain a way of
communicating and properties are symmetrical and non-
>observable.
> >
> >The implementing class cannot "know" when a property has
> On Mon, Oct 15, 2012 at 6:02 PM, Clint Priest wrote:
> > Because fundamentally interfaces are designed to explain a way of
> > communicating and properties are symmetrical and non-
> observable.
> >
> > The implementing class cannot "know" when a property has changed.
>
> Do you agree that the
On Mon, Oct 15, 2012 at 10:07 PM, Etienne Kneuss wrote:
> On Mon, Oct 15, 2012 at 6:45 PM, Lester Caine wrote:
>> Etienne Kneuss wrote:
>>>
>>> I can understand why we might not want that in PHP in order to
>>> simplify the implementation, but it we follow logical reasoning I
>>> can't see why we
On Mon, Oct 15, 2012 at 6:45 PM, Lester Caine wrote:
> Etienne Kneuss wrote:
>>
>> I can understand why we might not want that in PHP in order to
>> simplify the implementation, but it we follow logical reasoning I
>> can't see why we shouldn't implement that.
>
>
> With a decent IDE you don't nee
Etienne Kneuss wrote:
I can understand why we might not want that in PHP in order to
simplify the implementation, but it we follow logical reasoning I
can't see why we shouldn't implement that.
With a decent IDE you don't need any of this overhead anyway. When you see the
sorts of increase in
Hi,
On Mon, Oct 15, 2012 at 6:02 PM, Clint Priest wrote:
> Because fundamentally interfaces are designed to explain a way of
> communicating and properties are symmetrical and non-observable.
>
> The implementing class cannot "know" when a property has changed.
Do you agree that there is nothin
Because fundamentally interfaces are designed to explain a way of communicating
and properties are symmetrical and non-observable.
The implementing class cannot "know" when a property has changed.
-Clint
On Oct 15, 2012, at 9:37 AM, "Levi Morrison" wrote:
>> I *think* we are on the same page
> I *think* we are on the same page here, though I'm not sure what 'user' is
> referring to (user of interface "implementer") or (user of class B). In any
> case, I don't believe that your class B would be allowed at present, but if
> it is, then it should not be allowed because defining a prop
> -Original Message-
> From: ekne...@gmail.com [mailto:ekne...@gmail.com] On Behalf Of Etienne Kneuss
> Sent: Monday, October 15, 2012 9:10 AM
> To: Clint Priest
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Interface
On Mon, Oct 15, 2012 at 8:09 AM, Etienne Kneuss wrote:
> Hi,
>
> On Mon, Oct 15, 2012 at 3:55 PM, Clint Priest wrote:
>> I would bet, that at present, what you've put down is not allowed because I
>> purposely leveraged functions in this regard because all of the restrictions
>> put in place ag
gt; -Original Message-
>> From: ekne...@gmail.com [mailto:ekne...@gmail.com] On Behalf Of Etienne
>> Kneuss
>> Sent: Monday, October 15, 2012 8:29 AM
>> To: Clint Priest
>> Cc: Nikita Popov (nikita@gmail.com); internals@lists.php.net
>> Subject: Re: [PH
Message-
> From: ekne...@gmail.com [mailto:ekne...@gmail.com] On Behalf Of Etienne Kneuss
> Sent: Monday, October 15, 2012 8:29 AM
> To: Clint Priest
> Cc: Nikita Popov (nikita@gmail.com); internals@lists.php.net
> Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Int
Hi,
>
> Interfaces are a tough one, I would just like to point out that, again
> accessors are fundamentally different than properties, they just happen to
> share the same "use" syntax but act entirely differently. The difficulty
> with allowing an interface to enforce a property is that the
* I'm moving this into its own mail thread because talking about 5 different
topics under the same chain is ridiculous (has anyone suggested forums instead
of email??)
> So here comes my round of feedback on the current proposal.
>
> But before getting to that: I have collected a bit of data
28 matches
Mail list logo
