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
Here is a copy of what Dennis had written to me regarding automatic
implementations from C# (the model):
> Originally, C# did not support automatically implemented properties.
> There are several reasons why they were added. The first reason, is that
> while the syntax for properties is the sa
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:
I'm having some trouble setting up the re2c to allow the isset/unset. Here are
the definitions, I've added the two T_ISSET statements:
accessors:
accessor_function
accesso
Anyone have any help with this?
$1 of the first T_ISSET is matching against "\n\t\tisset {..." (... being the
rest of the set body through to the end of the script.
-Original Message-----
From: Clint Priest [mailto:cpri...@zerocue.com]
Sent: Wednesday, April 25, 2012 1
ay, May 05, 2012 10:19 AM
To: Clint Priest
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Trouble with zend_language_parser.y
Hi,
2012/4/26 Clint Priest :
> I'm having some trouble setting up the re2c to allow the isset/unset. Here
> are the definitions, I've added
turday, May 05, 2012 10:07 AM
> To: Clint Priest
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] RE: Trouble with zend_language_parser.y
>
> Hi Clint,
>
> On Wed, May 2, 2012 at 3:23 PM, Clint Priest wrote:
> > Anyone have any help with this?
>
> hard
That makes complete sense, it is indeed a LONG type that's getting to that
point, thank you!
> -Original Message-
> From: Nikita Popov [mailto:nikita@googlemail.com]
> Sent: Monday, May 07, 2012 2:27 PM
> To: Clint Priest
> Cc: Etienne Kneuss; Felipe Pena
I've been using array decomposition in other languages such as Javascript
recently and find it very useful. I did not find any conversation about it in
the archives, has this topic been discussed/vetted/shot down already?
Example use case: Indexed database results being iterated:
Input:
$tValu
would be really
incredible for PHP as well.
I see on that document it does not talk about a complex destructuring such as
I've described above.
My email here was to find if this would garner any interest from the PHP
community.
> -Original Message-
> From: Ivan Enderl
This has already been covered quite a bit, the problem with your suggestion is
that the compiler needs to determine the type it is cast to, which is why the
__toInt(), __toArray(), etc, so that the language can request the type it needs
to cast to.
> -Original Message-
> From: Seva Laps
Ironically enough, he's probably the only "whole man" of the Lannisters really.
> -Original Message-
> From: Stas Malyshev [mailto:smalys...@sugarcrm.com]
> Sent: Sunday, May 13, 2012 6:23 PM
> To: Ferenc Kovacs
> Cc: PHP internals
> Subject: Re: [PHP-DEV] Re: [VOTE] Vote change for empty(
Both of the RFC's you reference are for casting TO a scalar, not TO an object
type. Your pastbin is for casting FROM a scalar TO an object.
-Original Message-
From: Seva Lapsha [mailto:seva.lap...@gmail.com]
Sent: Monday, May 14, 2012 6:18 AM
To: Clint Priest
Cc: inte
How would one use your Castable interface to cast a Class "Test" to any of
integer, array or boolean?
From: Seva Lapsha [mailto:seva.lap...@gmail.com]
Sent: Monday, May 14, 2012 12:19 PM
To: Clint Priest
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Custom Casting
My past
Has anyone ever used the zend_compile_string() within the c code for compiling
internally created php? Is it frowned upon or has it never come up before?
In writing the accessors code I have several parts that are effectively just
mimicking what a simple zend_compile_string() would accomplish 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
+1 :)
> -Original Message-
> From: Kris Craig [mailto:kris.cr...@gmail.com]
> Sent: Friday, July 13, 2012 11:47 AM
> To: Anthony Ferrara
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] 6.0 And Moving Forward
>
> >
> >
> > 4. Rewrite the entire parser completely. I keep hearing abou
It's been a while since I posted any updates about this, a few individuals have
been asking about it privately and wanting me to get it out the door for PHP
5.5 release. It's come a long way since the last time I posted about it.
RFC Document: https://wiki.php.net/rfc/propertygetsetsyntax-as-im
27;s <.01s difference.
Depending on the run it is sometimes exactly the same performance.
> -Original Message-----
> From: Clint Priest [mailto:cpri...@zerocue.com]
> Sent: Monday, October 08, 2012 6:53 AM
> To: internals@lists.php.net
> Subject: [PHP-DEV] [RFC] Propety Accessors
2 7:50 AM
> To: Clint Priest
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1
>
> Good work Clint!
>
> Performance is probably one of the things people will complain about so it's
> good that your benchmark is proving that it'
nstant, which is quite nice. The
> typehinting is a big plus as well.
>
> On Mon, Oct 8, 2012 at 3:26 PM, Benjamin Eberlei wrote:
>
> > The set() one is really nice with the typehints.
> >
> > On Tue, Oct 9, 2012 at 12:19 AM, Aaron Holmes
> > wro
, October 08, 2012 10:08 PM
To: Clint Priest
Cc: internals@lists.php.net; Aaron Holmes; Benjamin Eberlei
Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1
While I understand your concern with set being the only keyword using (), and
even agree it's a bit problematic, I see a big problem with
Wow, I'm surprised by all the talk about this RFC this time around. I posted
this numerous times in the past trying to elicit feedback and got little to
none, so I took the time to write it as I thought it should be written. Some
of these things will take considerable effort to fix/correct/cha
> On 10 October 2012 01:16, Johannes Schlüter wrote:
> > Up until now reflection is leaky and is telling the truth. We should
> > either keep that or completely clean up reflection.
>
> Reflection should always tell the truth, or there is no point in it.
>
Unfortunately the "truth" here is subj
> > Second, I'd like to throw in the idea of array accessors. I mentioned
> > this before, but did not get any response.
> >
> > public $Addresses {
> > offsetSet($offset, $value) { ... }
> > offsetGet() { ... }
> > offsetUnset($offset) { ... }
> > offsetExists($offset) { ... }
> >
> >> What concerns me with the current implementation is that it leaks
> >> many implementation details, in particular the fact that the
> >> accessors are implemented as *real* __getXYZ methods and automatic
> >> implementations also use *real* $__XYZ properties.
>
> > I don't particularly see th
> On Wed, Oct 10, 2012 at 5:51 AM, Clint Priest wrote:
> > I'm not even sure that automatic backing fields are even desired, I
> > never felt the need to have them in C# and the only reason they were
> > included is because they were a part of Dennis's original
> field(s) protected - this would be the equivalent of
> declaring a read-only accessor that you are permitted to extend with a
> write-accessor if you need to...
>
>
> -- Forwarded message --
> From: Jazzer Dane
> To: Leigh
> Cc: Clint Priest , "int
Okay, I would like this to be the last time there are revisions to this RFC.
To sum up the last few days of conversations, I have these down as points of
contention:
1. Accessor functions should not be present on the object and callable
directly, for example, $o->__getHours() should not be a
the few modern languages
that does not have such a feature.
> -Original Message-
> From: Levi Morrison [mailto:morrison.l...@gmail.com]
> Sent: Wednesday, October 10, 2012 8:27 PM
> To: Clint Priest
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] [RFC] Propety Acces
Wednesday, October 10, 2012 9:18 PM
To: Clint Priest
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1
This all sounds about right.
In regards to #4 - read-only/write-only:
I think that, from a "pretty syntax" point of view, private final set() {} and
privat
What about private final set($value) { } tells you that it's read only? There
is a setter.
From: Pierre Joye [mailto:pierre@gmail.com]
Sent: Thursday, October 11, 2012 12:05 AM
To: Clint Priest
Cc: PHP internals; Jazzer Dane
Subject: RE: [PHP-DEV] [RFC] Propety Accessors v1.1
On O
This would produce a compile error, cannot define set, property is read-only.
> -Original Message-
> From: Pierre Joye [mailto:pierre@gmail.com]
> Sent: Thursday, October 11, 2012 7:43 AM
> To: Sebastian Krebs
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] [RFC] Propety Accesso
greement...
Or... do ya'll want to vote on the aforementioned changes?
> -Original Message-
> From: Clint Priest [mailto:cpri...@zerocue.com]
> Sent: Wednesday, October 10, 2012 7:36 PM
> To: internals@lists.php.net
> Subject: RE: [PHP-DEV] [RFC] Propety Accessors v1.1
&g
er 11, 2012 6:42 PM
To: Clint Priest
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1
You really don't want to even think about my idea? It's complementary on some
aspects, you know.
2012/10/11 Clint Priest mailto:cpri...@zerocue.com>>
Rather than
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 leave this open for the two week waiting period while I
make th
I must have missed taking that part out of the RFC, they would not be needed
any more with those keywords being removed.
> -Original Message-
> From: Levi Morrison [mailto:morrison.l...@gmail.com]
> Sent: Friday, October 12, 2012 9:45 AM
> To: Clint Priest
> Cc: internal
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,
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
/Property_%28programming%29
Lastly, it would probably delay this project another 6 months, perhaps it could
be shelved for a version 2 of the accessors aspect?
-Clint
> -Original Message-
> From: Bernhard Schussek [mailto:bschus...@gmail.com]
> Sent: Friday, October 12, 2012 3:07 AM
Interfaces are used to define what methods must be present, properties are not
allowed.
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
> > 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
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.
-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?
r, you can rely on the fact
that anyone who implements that interface *must* implement an accessor of the
given name.
From: amaury.bouch...@gmail.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; Benjam
* 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
* 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
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
> 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
__get
v1.4 @ 10/8/20121m .04sn/a
.21s
"Direct" vs "Getter" vs "__get" on 1 million cycles.
> -Original Message-
> From: Levi Morrison [mailto:morrison.l...@gmail.com]
> Sent: Monday, Octo
> -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
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
> 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 prop
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
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 /
AM
> To: Paul Dragoonis
> Cc: Clint Priest; internals@lists.php.net
> Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1
>
> Hi!
>
> > What remains on your TODO list for this functionality?
> > When are you planning to run an RFC vote on this?
> >
> >
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
> -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 :
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
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
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, "
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
pulled from the original RFC that Dennis wrote some 4 years
ago. Perhaps we don't even NEED a solution to this problem.
> -Original Message-
> From: Stas Malyshev [mailto:smalys...@sugarcrm.com]
> Sent: Tuesday, October 16, 2012 5:59 AM
> To: Jazzer Dane
> Cc: Clint Priest
Is it just me or has this Property Accessors chain of emails been impossible to
make heads or tails of? People replying within replies within replies, quoting
partial emails, cross-posting and all sorts of chaos.
Would anyone be willing to entertain an alternative "communication method" with
s
I was thinking more along the lines of a collaborative wiki with
inline-threaded comments...
> -Original Message-
> From: Jan Ehrhardt [mailto:php...@ehrhardt.nl]
> Sent: Tuesday, October 16, 2012 8:00 PM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] Alternatives to mailing list?
> Sent: Wednesday, October 17, 2012 4:43 AM
> To: Lester Caine
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] Alternatives to mailing list?
>
> hi,
>
> On Wed, Oct 17, 2012 at 11:21 AM, Lester Caine wrote:
> > 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 output, your arguments about isset()/unset()
are just plain
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
>
?
> -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
I was really referring to another tool to collaborate on an RFC document,
something where comment threads can be started and replied to from within the
context/section of the RFC that the comment belongs to.
Ive looked at a few other wikis and some have this capability... Github could
be close
Who's the karma keeper anyways? Do we get a score? ;)
> -Original Message-
> From: Pierre Joye [mailto:pierre@gmail.com]
> Sent: Thursday, October 18, 2012 5:03 AM
> To: Marcello Duarte
> Cc: PHP internals; Hannes Magnusson; Derick Rethans
> Subject: Re: [PHP-DEV] Wiki account
>
> Wh
Could just as easily launch N sub-processes from run-tests.php as well.
I compile php in a VM with -j 40 on a dual core VM powered by quad core chip...
The number of simultaneous tests doesn't need to line up with CPU counts...
-Clint
On Oct 18, 2012, at 7:28 AM, "Pierre Joye" wrote:
> hi!
>
Got an email?
-Clint
On Oct 18, 2012, at 7:29 AM, "Kris Craig"
mailto:kris.cr...@gmail.com>> wrote:
On Thu, Oct 18, 2012 at 4:58 AM, Clint Priest
mailto:cpri...@zerocue.com>> wrote:
Who's the karma keeper anyways? Do we get a score? ;)
I'm not 100% sure, b
Hey everyone, seems like the conversations have died down and I've attempted to
go back through all of the emails and produce a 1.1 -> 1.2 document which
summarizes what I believe are decided, being debated, issues, todos, etc.
Pierre had pointed out that I had partially changed the "as-implemen
I had thought of a deviation on some of the ideas presented to get rid of
read-only/write-only while still keeping the ability to maintain their effect,
if we so decide that the feature is wanted. Here it is:
class TimePeriod {
private $Seconds;
public $Hours {
get() { return $
gt; From: Pierre Joye [mailto:pierre@gmail.com]
> Sent: Saturday, October 20, 2012 5:16 AM
> To: Clint Priest
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] [RFC] Accessors v1.1 -> v1.2 Summary
>
> On Sat, Oct 20, 2012 at 1:06 AM, Clint Priest wrote:
> > Hey every
way. For most properties that only have a
> read-accessor, it won't even make any sense for someone
> to try to extend that with a write-accessor. And as said, if you want to keep
> the internal value safe from write, just declare the actual
> property as private.
>
> -
I think that seems to be the consensus at this point, anyone disagree?
> -Original Message-
> From: Levi Morrison [mailto:morrison.l...@gmail.com]
> Sent: Sunday, October 21, 2012 10:26 AM
> To: Amaury Bouchard
> Cc: Nikita Popov; Clint Priest; internals@lists.php.net
>
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
Recursion is guarded by the same mechanism __get uses to avoid recursion.
On 10/26/2012 9:33 AM, Stas Malyshev wrote:
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
That's basically what #2 is getting at, my only question is, emit a
warning or notice or not?
Technically returning false on an invalid isset() call could be
misleading without emitting some kind of notice or warning about it.
On 10/26/2012 9:56 AM, Stas Malyshev wrote:
Hi!
1. If al
On 10/26/2012 9:39 AM, Stas Malyshev wrote:
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 var
That's why I think they shouldn't even be visible to users, they aren't
relevant to them and in fact it could mis-lead them into thinking that
they could simply define __getHours() and expect $foo->Hours to call
it, which it wouldn't.
To me, the bottom line is, the fact that there are methods
On 10/26/2012 6:37 PM, Stas Malyshev wrote:
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 wher
Sorry I guess I should have been more clear. The recursion would
prevent the accessor from being called which would allow the ordinary
property code to execute, thus accessing the property directly. I
suppose if it were in a setter and the property were not defined by the
accessor then it wou
erly named accessor function. Failing that it would then check for
the existence of a property and failing that move on to looking up __get
-Clint
On 10/27/2012 2:14 PM, Patrick Schaaf wrote:
On Saturday 27 October 2012 13:05:27 Clint Priest wrote:
That's why I think they shouldn'
Stas, you should probably do some research before posting such non-sense:
http://en.wikipedia.org/wiki/Property_%28programming%29
Every language you mentioned has them. Perhaps the confusion is that I
am calling them accessors since other languages refer to accessors as
"properties" while PHP
:48:12 PM, Larry Garfield wrote:
On 10/27/2012 09:38 PM, Larry Garfield wrote:
On 10/26/2012 05:37 AM, Clint Priest wrote:
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:/
On 10/28/2012 2:04 AM, Stas Malyshev wrote:
Hi!
Stas, you should probably do some research before posting such non-sense:
Which part is "non-sense"? I've brought you examples of Python and Ruby
not doing exactly what you claim all languages are doing. By your
definition, they don't have access
ll (since the value cannot be retrieved).
On Sunday, October 28, 2012 4:02:23 AM, Pierre Joye wrote:
hi Clint,
On Sat, Oct 27, 2012 at 7:39 PM, Clint Priest wrote:
That's basically what #2 is getting at, my only question is, emit a warning
or notice or not?
Technically returning false on
Well I guess this and many of the other issues from other threads are
the reasons I had it written the way that it is currently (basically an
extension of __get()) but numerous other proposals have muddied the
situation.
On Sunday, October 28, 2012 2:17:47 AM, Stas Malyshev wrote:
Hi!
Sorry
ir wrote:
On 29/10/12 03:02, Clint Priest wrote:
So... to be explicit here, you think in this situation:
class a {
public $b {
set($x) { $this->b = $x; }
}
}
$o = new a();
if(!isset($o->b)) {
/* delete files */
}
echo (int)isset($o->b); /* This should return false and not emi
Would you say the same of unset? Always benign?
On 10/29/2012 2:14 PM, Stas Malyshev wrote:
Hi!
So... to be explicit here, you think in this situation:
class a {
public $b {
set($x) { $this->b = $x; }
}
}
$o = new a();
if(!isset($o->b)) {
/* delete files */
}
echo (int)
ee?
On 10/26/2012 5:37 AM, Clint Priest wrote:
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
*sigh*
Which error would make more sense to you Stas...
Given this code:
class a {
public $b {
get() { return 5; }
private set($x) { /* do something */ }
}
}
$o = new a();
echo $o->b;
$o->b = 42;
There are two possibilities at this point. The code base, without all
1 - 100 of 192 matches
Mail list logo
