Hi!
> I think we are still not on the same page here. The exact point is
> to *not* put accessors into the method table. As such the accessors
> aren't special, half-hidden methods (like they are with the current
> implementation), rather they are *just* accessors and nothing else.
Accessors ar
?
> -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
2012/10/17 Stas Malyshev
> No, you don't get an error. You'd get an error in compiled language. In
> dynamic language, your client gets an error when his site is launched
> and instead of happy launch his users get white screens. To avoid that,
> you'd need to add checks - or just ship it as is a
I've been re-reading the last few days of posts to collect what is to be
changed about the RFC on what has seemed to come to a consensus and my
apologies Stas, I did not catch exactly what you meant by this statement:
> > Exactly my point. Your code (with != NULL) will return false while real
>
On Wed, Oct 17, 2012 at 1:51 PM, Clint Priest wrote:
>> > This isn't the way isset() works, isset() will return true for a
>> > variable with a value of 0
>>
>> Exactly my point. Your code (with != NULL) will return false while real
>> isset() will return true.
>
> Stas, please see this execution
> > This isn't the way isset() works, isset() will return true for a
> > variable with a value of 0
>
> Exactly my point. Your code (with != NULL) will return false while real
> isset() will return true.
Stas, please see this execution output, your arguments about isset()/unset()
are just plain
On Wed, Oct 17, 2012 at 1:24 PM, Stas Malyshev wrote:
> Hi!
>
>> You have already written seven mails all saying how much complexity
>> this would introduce. Could you maybe elaborate a bit on that? How
>> would it make anything more complex? I mean, the only really
>
> Any code that deals with me
Hi!
> You have already written seven mails all saying how much complexity
> this would introduce. Could you maybe elaborate a bit on that? How
> would it make anything more complex? I mean, the only really
Any code that deals with methods would now have to consider - is this
regular method or spe
On Wed, Oct 17, 2012 at 1:07 PM, Stas Malyshev wrote:
>> I see this argument crop up with every typehint discussion and just
>> don't understand it at all. Why would you want to check the variable
>> type everywhere? You just assign it and if it doesn't work, then you
>> get an error. Just like it
On Wed, Oct 17, 2012 at 12:11 PM, Stas Malyshev wrote:
> Hi!
>
>> That makes some sense, still the issue Nikita brought up is that the
>> __getHours() should not be callable.
>
> I don't see any use case for this requirement. What *requires* that it
> won't be callable and why it is so necessary t
Hi!
> I see this argument crop up with every typehint discussion and just
> don't understand it at all. Why would you want to check the variable
> type everywhere? You just assign it and if it doesn't work, then you
> get an error. Just like it should be. I mean, do you seriously check
No, you do
On Tue, Oct 16, 2012 at 12:55 PM, Stas Malyshev wrote:
>> Last thing: I agree with Clint and you. If it was early checked, it
>> would be better. But the current type hinting is far better than nothing
>> at all. Yes, we can't "lint" it, but it was pretty useful a big number
>
> No, it's not bette
On Mon, Oct 15, 2012 at 2:11 PM, Clint Priest wrote:
> So the above would actually introduce an get/set accessor rather than a
> property, correct?
Preferably it would a faster C based implementation for the check, but
in principle it could also use accessors to achieve the goal.
> If we were to
On Tue, Oct 16, 2012 at 11:58 AM, Stas Malyshev wrote:
>> Type hinting in parameters is a really good thing, and it doesn't
>> transformed PHP in a strongly typed language.
>
> It however gave a permission to people to try sneak in strong-typedness
> through various backdoors arguing exactly that:
Hi!
> It is foolish to think that these two bits of code are behaviorally different:
>
> class Entity {
> DateTime $last_modified;
> }
The are different because this one looks like a strongly typed variable
which brings with it a lot of connotations which aren't immediately
obvious, and in f
Hi!
> That makes some sense, still the issue Nikita brought up is that the
> __getHours() should not be callable.
I don't see any use case for this requirement. What *requires* that it
won't be callable and why it is so necessary that we introduce
additional complexity into the engine just to do
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
; internals@lists.php.net
> Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
>
> Hi!
>
> > I apologize for my confusing terminology - let me elaborate. There are
> > no special syntaxes. The below code should help clear things up a bit:
> >
> >
lys...@sugarcrm.com]
> Sent: Tuesday, October 16, 2012 5:48 AM
> To: Jazzer Dane
> Cc: Clint Priest; internals@lists.php.net
> Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
>
> Hi!
>
> > Stas, the proposed "solution" thus far is to make t
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, "
On Tue, Oct 16, 2012 at 10:31 AM, Amaury Bouchard wrote:
> 2012/10/16 Rasmus Lerdorf
>>
>> The rule in PHP for any sort of type hinting is that it is only done for
>> non-coercable types. In cases where there is simply no way to recover
>> from passing the wrong type, it is good to catch it as ea
2012/10/16 Rasmus Lerdorf
> The rule in PHP for any sort of type hinting is that it is only done for
> non-coercable types. In cases where there is simply no way to recover
> from passing the wrong type, it is good to catch it as early as
> possible. Extending this to also cover scalar coercable
On 10/16/2012 02:51 AM, Amaury Bouchard wrote:
> 2012/10/16 Stas Malyshev
>
public DateTime $date;
>>>
>>> This is *real* progress, even if under the hood all it does is wrap
>>
>> I think it's a movement in wrong direction. Again, it is an attempt to
>> make PHP a strongly typed language, w
Hi!
> I very much disagree, engine details should not be visible to users.
> It is irrelevant to them and only serves to confuse.
It's not engine detail. We're not talking about exposing C pointers or
zend_op values. We're talking about implementing methods that have
special meaning. They are sti
2012/10/16 Clint Priest
> In this regard, I have yet to see any proposal that is as clear or concise
> as public read-only $abc. What is the big problem with adding read-only
> and write-only keywords? Once they are in the language they could be
> expanded to plain properties.
public:const $a
Gabeezus, I have to get to work Stas! ;)
> > This is the way it is, though Nikita strongly disagrees that they
> > should be "callable, visible" methods on the object and I agree with
> > Nikita on this issue, I never did like the idea that __getHours() and
>
> I think PHP engine has enough compl
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
and as shown above it would be nonsensical to have
> written PHP like that.
>
> ** **
>
> ** **
>
> *From:* Jazzer Dane [mailto:tbprogram...@gmail.com]
> *Sent:* Tuesday, October 16, 2012 6:45 AM
> *To:* Clint Priest
> *Cc:* Stas Malyshev; internals@lists.php.net
>
Hi!
> This is the way it is, though Nikita strongly disagrees that they
> should be "callable, visible" methods on the object and I agree with
> Nikita on this issue, I never did like the idea that __getHours() and
I think PHP engine has enough complexity and we do not need to add more
unwarrante
P like that.
From: Jazzer Dane [mailto:tbprogram...@gmail.com]
Sent: Tuesday, October 16, 2012 6:45 AM
To: Clint Priest
Cc: Stas Malyshev; internals@lists.php.net
Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
private final get/set() {} is indeed not a read/write only functional
private final get/set() {} is indeed not a read/write only functionality. I
really would like to keep new keywords out of whatever syntax is
implemented, but I think the latest proposal can and should be improved
upon.
I've been thinking about this quite a bit.
To reiterate the initial problem, al
> -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 :
Hey Stas, a bunch of this has already been covered but I will attempt to answer
each of these as is my current understanding of "the hives" decision... :P
> 1. Accessors IMO should be regular PHP methods that PHP generates with two
> additional things:
> a. Their name is generated by PHP
> b. Th
Excuse my late-night-influenced terminology, the word "empty" is much more
suitable than "does not have".
And this "solution" really is more of a hack or work-around than a solution.
I do think that there is a better way to go about implementing
read/write-only, but nothing has come to mind as of
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
Hi!
> I apologize for my confusing terminology - let me elaborate. There are
> no special syntaxes. The below code should help clear things up a bit:
>
> class MyClass {
> private $otherProperty;
> public $property {
> get() {}; // Does not "have a body", as there is no co
Hi!
> If the first could be useful, the second could be useful too. Or you are
> saying that parameters type hinting was a bad idea?
Given how it is understood now - as a first step to make PHP a strongly
typed language - yes, I'm starting to think it was. If it was understood
as it was intended
I apologize for my confusing terminology - let me elaborate. There are no
special syntaxes. The below code should help clear things up a bit:
class MyClass {
> private $otherProperty;
> public $property {
> get() {}; // Does not "have a body", as there is no code between the
> curly braces
Hi!
> Stas, the proposed "solution" thus far is to make the getter or setter
> final and private and not have a body. This would naturally throw an
> exception if it was accessed from anywhere but the class it was defined.
> The class it was defined in has to remember that it is virtually a
> read
2012/10/16 Stas Malyshev
> Also, the fact is that other dynamic languages do not
> have strong typing. It may be they just aren't smart enough to recognize
> everybody needs it - or there may be a reason why it doesn't happen. I
> think there is a reason
>
> > Doing the same for object properties
as Malyshev [mailto:smalys...@sugarcrm.com]
> Sent: Tuesday, October 16, 2012 4:58 AM
> To: Amaury Bouchard
> Cc: Levi Morrison; Clint Priest; internals@lists.php.net; Nikita Popov
> (nikita@gmail.com)
> Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Typehints /
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
Stas, the proposed "solution" thus far is to make the getter or setter
final and private and not have a body. This would naturally throw an
exception if it was accessed from anywhere but the class it was defined.
The class it was defined in has to remember that it is virtually a
read/write only acc
Hi!
> In regards to #11, yes, you'd just write {}. I imagine you could also
This doesn't work for the same class (and for traits which put things in
the context of the same class) - it would not behave as "no setter", it
would behave as "there's a setter doing nothing". Is this the proposed
solut
In regards to #11, yes, you'd just write {}. I imagine you could also just
throw an exception. Maybe an exception could be thrown automatically if
there is no code between the braces. Though this doesn't really directly
relate to providing the ability to disable get/set in an accessor.
The only cl
Hi!
> Not necessarily strongly typed. (sorry to land on this topic afterwards)
> As I see PHP, it's a language that can be used as an informal scripting
> language, but also as a rock-solid modern tool.
I have no idea what "rock-solid modern tool" means, though PHP is
trivially a modern tool by b
Hi!
> Not necessarily strongly typed. (sorry to land on this topic afterwards)
> As I see PHP, it's a language that can be used as an informal scripting
> language, but also as a rock-solid modern tool.
I have no idea what "rock-solid modern tool" means, though PHP is
trivially a modern tool by b
2012/10/16 Stas Malyshev
> >> public DateTime $date;
> >
> > This is *real* progress, even if under the hood all it does is wrap
>
> I think it's a movement in wrong direction. Again, it is an attempt to
> make PHP a strongly typed language, which would not work well in a
> dynamic language like
Hi!
> #5: From what I understand, an extending class can not override an
> accessor with a non-accessor.
This should be in the RFC then - along with what exactly happens. Note
that this will represent a sort of BC break in terms that you could have
two properties $a before, but if you change impl
#2: I agree with you here - this is problematic. isset/unset accessors that
invoke the isset/unset function should actually invoke the function rather
than being compared to null, as that isn't the same as isset.
#5: From what I understand, an extending class can not override an accessor
with a no
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
Hi!
> https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
My feedback on the RFC:
1. Accessors IMO should be regular PHP methods that PHP generates with
two additional things:
a. Their name is generated by PHP
b. Their argument set is defined by the accessor pattern (i.e. same
thing as
Hi!
>> public DateTime $date;
>
> This is *real* progress, even if under the hood all it does is wrap
I think it's a movement in wrong direction. Again, it is an attempt to
make PHP a strongly typed language, which would not work well in a
dynamic language like PHP, for reasons that were amply e
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
ber 15, 2012 9:16 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 : Backing
> Property
>
> > But here are some issues with the above that may be of concern:
> > *
> 1) Point taken.
>
> 2) The use case can be solved with an object implementing ArrayAccess, but
> not pragmatically, because then you need a class for
> *each* bidirectional association. Let me give a short example:
>
> Given the class Article with a bidirectional many-to-one relation to Catego
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
> But here are some issues with the above that may be of concern:
> * Property access is 4x faster than accessor method calling
4x faster on what kind of scale? Where are these performance tests at?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www
> public DateTime $date;
This is *real* progress, even if under the hood all it does is wrap
functions and use function type-hints. This piece of code is SO much
shorter and cleaner. Will it be a bit confusing to new developers?
Maybe, but I don't care. It is not aimed at making the lives of new
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 3* 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 dat
* 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
* 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
On Sun, Oct 14, 2012 at 10:55 PM, Jazzer Dane wrote:
> One of the reasons the current syntax, as seen below, was chosen, is for
> typehints - yes.
>
>> public $property {
>> get() { ... }
>> set{TypeHint $value) { ... }
>> }
>>
> The other reason it was chosen was to specifically get rid of th
One of the reasons the current syntax, as seen below, was chosen, is for
typehints - yes.
> public $property {
> get() { ... }
> set{TypeHint $value) { ... }
> }
>
The other reason it was chosen was to specifically get rid of the magic
$value that appeared out of thin air. If typehints become
On Sun, Oct 14, 2012 at 2:50 PM, Nikita Popov wrote:
> On Fri, Oct 12, 2012 at 7:23 AM, Clint Priest wrote:
>> Alright, here is the updated RFC as per discussions for the last few days:
>>
>> https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
>>
>> If you could read it over, make sure I
On Fri, Oct 12, 2012 at 7:23 AM, Clint Priest wrote:
> Alright, here is the updated RFC as per discussions for the last few days:
>
> https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
>
> If you could read it over, make sure I have all of your concerns correctly
> addressed and we can
il.com [mailto:amaury.bouch...@gmail.com] *On
> Behalf Of *Amaury Bouchard
> *Sent:* Sunday, October 14, 2012 3:23 AM
> *To:* Clint Priest
> *Cc:* Nikita Popov; Benjamin Eberlei; internals@lists.php.net
>
> *Subject:* Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
>
>
in Eberlei; internals@lists.php.net
Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
You are right, we can define __get() in an interface. So, in the end I will
shut my mouth.
But still, it's not logical. An interface is a contract which defines the
capacities of an object.
Hi Clint,
1) Point taken.
2) The use case can be solved with an object implementing ArrayAccess,
but not pragmatically, because then you need a class for *each*
bidirectional association. Let me give a short example:
Given the class Article with a bidirectional many-to-one relation to
Category a
You are right, we can define __get() in an interface. So, in the end I will
shut my mouth.
But still, it's not logical. An interface is a contract which defines the
capacities of an object. If an interface defines the entry point swim(), we
know that an object which implements this interface is ab
-Clint
On Oct 13, 2012, at 4:21 PM, "Amaury Bouchard"
mailto:ama...@amaury.net>> wrote:
2012/10/13 Clint Priest mailto:cpri...@zerocue.com>>
Interfaces are used to define what methods must be present, properties are not
allowed.
Yes, so no one should be correct, right?
I mean, yes the first
2012/10/13 Clint Priest
>Interfaces are used to define what methods must be present, properties
> are not allowed.
>
> ** **
>
> Yes, so no one should be correct, right?
>
> I mean, yes the first declaration implies some code; but for the
> interface, it's still a property definition.
mail.com>] On Behalf
Of Amaury Bouchard
Sent: Saturday, October 13, 2012 5:06 AM
To: Nikita Popov
Cc: Benjamin Eberlei; Clint Priest;
internals@lists.php.net<mailto:internals@lists.php.net>
Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
2012/10/13 Nikita Popov mailto:nikita.
> > On Sat, Oct 13, 2012 at 6:47 AM, Clint Priest wrote:
> > The problem with that Nikita is that it would need a variable storage
> > location, which would mean a hidden, auto-implemented property. You were
> > dead-set against that from the get go.
> What I was mainly against was the particul
.
> *From:* amaury.bouch...@gmail.com [mailto:amaury.bouch...@gmail.com] *On
> Behalf Of *Amaury Bouchard
> *Sent:* Saturday, October 13, 2012 5:06 AM
> *To:* Nikita Popov
> *Cc:* Benjamin Eberlei; Clint Priest; internals@lists.php.net
>
> *Subject:* Re: [PHP-DEV] [PH
@lists.php.net
Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
2012/10/13 Nikita Popov mailto:nikita@gmail.com>>
interface Foo {
// this is okay
public $abc { get; set; }
// this is invalid
public $abc;
}
Sorry, I missed something. Why the
2012/10/13 Nikita Popov
> interface Foo {
> // this is okay
> public $abc { get; set; }
>
> // this is invalid
> public $abc;
> }
>
Sorry, I missed something. Why the first should be correct but not the
second one?
For me it's exactly the same thing.
On Sat, Oct 13, 2012 at 11:29 AM, Nikita Popov wrote:
> On Sat, Oct 13, 2012 at 10:06 AM, Benjamin Eberlei
> wrote:
> > Can we discuss the removal of automatic get; set; again? For me that was
> > the best feature of the whole RFC, essentially allowing to define a
> > property with getter/setter
On Sat, Oct 13, 2012 at 6:47 AM, Clint Priest wrote:
> The problem with that Nikita is that it would need a variable storage
> location, which would mean a hidden, auto-implemented property. You were
> dead-set against that from the get go.
What I was mainly against was the particular way how a
On Sat, Oct 13, 2012 at 10:06 AM, Benjamin Eberlei wrote:
> Can we discuss the removal of automatic get; set; again? For me that was
> the best feature of the whole RFC, essentially allowing to define a
> property with getter/setter in 1 LOC. Allowing future overriding of that
> getter/Setter if t
On Fri, Oct 12, 2012 at 7:23 AM, Clint Priest wrote:
> Alright, here is the updated RFC as per discussions for the last few days:
>
> https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
>
> If you could read it over, make sure I have all of your concerns correctly
> addressed and we can
> To: Clint Priest
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
>
> Hi Clint,
>
> I would like to urge you again to consider implementing the array access
> methods. Without that, this very neat feature becomes
> essential
AM
To: Clint Priest
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
I like it.
I assume that, in regards to static properties, the static keyword works just
as well as self and parent, correct?
On Thu, Oct 11, 2012 at 10:23 PM, Clint Priest
mailto:cpri
on point before proceeding?
> -Original Message-
> From: Nikita Popov [mailto:nikita@gmail.com]
> Sent: Friday, October 12, 2012 5:48 AM
> To: Clint Priest
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
>
> On Fri, Oct 12,
1 - 100 of 116 matches
Mail list logo
