It would be also good to know why people vote no.
+1 for that, even if only a brief sentence.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On 2/13/2023 4:13 AM, Arvids Godjuks wrote:
Good day dear Internals!
I've been following this thread/RFC from its inception to the current
moment. I have watched the situation deteriorate and at this point, I have
major concerns about the events that transpired, the motivations of some
decisio
On 1/19/2023 12:40 PM, Marco Pivetta wrote:
Not just that, but `debug_backtrace()` already exists for that purpose.
I have use debug_backtrace() exactly for this purpose in the past. It
was to make a protected property readable/writable, but only by certain
"friend classes."
It's pretty tr
Nikita,
I'm a bit worried that using this as a standard test suite may
(repeatedly?) give us a false sense of security to go ahead with
compatibility breaking changes.
Composer packages, almost by definition - tend to be of higher quality
than the 'average' PHP code (at the very least they're
Here here. :)
On 3/17/2013 5:45 AM, Nikita Popov wrote:
On Sun, Mar 17, 2013 at 10:03 AM, Ferenc Kovacs wrote:
I'm also interested about the rationale behind this design decision.
Just for the record, this would have been one of the things that the
accessors proposal would have added.
-
Unfortunately my experience with that process has been that many people
will vote who had no part in the discussion.
On 3/16/2013 3:16 PM, Sherif Ramadan wrote:
On Sat, Mar 16, 2013 at 5:28 AM, Sébastien Durand wrote:
Hi guys,
*I think it could be a nice little improvement to add an extra f
On 2/20/2013 2:35 PM, Christopher Jones wrote:
Hi Paul,
My thesis is the other way round. More people in the community need
to become PHP core developers. This is historically how PHP
development has occurred, since nobody has idle time to adopt projects
they are not 100% behind.
Increasing
There is also a PECL extension already under development that will
probably fill this void so many people would like to see filled.
On 2/25/2013 7:43 AM, Nils Andre wrote:
Hi Everyone on the list, I have no RFC Karma here so far, so I post this to
the list at first. There has been ongoing disc
On 2/21/2013 5:17 AM, David Muir wrote:
On 21/02/2013, at 6:12 AM, Lazare Inepologlou wrote:
Long code is not always equivalent to readable code. A shorter syntax could
improve readability in *some* cases.
Long:
$users->OrderBy( function( $x ){ return $x->Surname; } );
Short:
$users->Order
On 1/29/2013 6:54 PM, Stas Malyshev wrote:
Hi!
I think having stuff on the wiki is nice, but for things related to the
code - e.g., APIs, builds descriptions, etc. - they should stay in the
code. They are easier to find there and easier to keep up-to-date, and
also ensure they have the content r
On 1/17/2013 12:20 PM, Clint Priest wrote:
I'm happy to say that Property Accessors is ready for a vote for
inclusion in 5.5 release.
Nikita and I (as well as Stas a bit) have all been working hard to
make this happen for 5.5, voting and the specifications are here:
https://wiki.php.ne
On 1/29/2013 5:23 AM, Anthony Ferrara wrote:
Additionally, I don't like the precedent that this sets for future
releases. That it's ok to break the timebox for some feature. In this case
I think we can justify it, but future cases may use this to justify waiting
when it's not completely justified
On 1/28/2013 6:12 AM, Peter Cowburn wrote:
On 28 January 2013 12:03, Clint Priest wrote:
If you're still worried about this making it in, don't worry. Nikita and I
have given up, to the determinant of the community.
Then please close the voting.
Since there is no "maximum vot
On 1/28/2013 2:09 AM, Christian Stoller wrote:
In userland we can only do something like
$str = new String('my_string_class');
echo $str->length();
But that's useless.
It would be great if method calls on primitive types could be supported, like
in Nikic' proof of concept (https://github.com/n
On 1/28/2013 5:19 AM, Zeev Suraski wrote:
I feel that this is what was done in this particular case, not the
other way around. That what brought me to bring up that subject here
in the first place. This particular RFC was the only RFC where I
noticed this weird 'no sooner than' language, and i
On 1/25/2013 8:43 PM, Stas Malyshev wrote:
Hi!
Realistically couldn't we just introduce a configuration parameter to
keep "the inconsistent parameter order," perhaps along with a script to
suggest the changes needed to bring some code up to speed?
People think that "introduce a configuration
On 1/25/2013 7:02 PM, Stas Malyshev wrote:
Hi!
Well, how about renaming the functions, create aliases for BC and throw
E_DEPRECATED or E_STRICT on their usage? And write a PEAR script bundled
with the distribution to migrate to the new convention?
Well, the problem with these things is this:
On 1/25/2013 4:37 AM, Julien Pauli wrote:
On Fri, Jan 25, 2013 at 9:19 AM, Rasmus Lerdorf wrote:
And I can understand the lack of help. It is probably the most
complicated piece of the entire stack. It is a an op_array juggler doing
a complex dance on a tight rope backwards and blindfolded. I
On 1/23/2013 5:04 PM, Crypto Compress wrote:
guard->in_unset = 1; /* Prevent recursion */
zend_call_method_with_1_params(&object, zobj->ce, &zobj->ce->__unset,
ZEND_UNSET_FUNC_NAME, NULL, member);
guard->in_unset = 0; /* Prevent recursion */
a) That applies to __unset (magic method) only
b) g
On 1/23/2013 4:40 PM, Rasmus Lerdorf wrote:
I appreciate that, I'm hearing through the grapevine that some of the
"no" voters haven't even looked at the patch.
Just to be fair, I suspect quite a few "yes" voters haven't looked at,
nor understood the patch.
-Rasmus
I'd bet good money that's tr
On 1/23/2013 3:17 PM, Levi Morrison wrote:
Clint: I'm sorry that you spent all that time without hearing feedback
from a lot of the "No" voters. Had they been participating all along
perhaps it could have been avoided. We'll never know.
I appreciate that, I'm hearing through the grapevine that
On 1/23/2013 3:07 PM, Crypto Compress wrote:
> I'd just like to point out the fact that RFC v1.1 from a year ago
was exactly as above but people wanted all of these other features.
They were not a property, they had no "guarding", no unset, isset,
etc. The original RFC that was exactly as c# h
On 1/23/2013 1:00 PM, Marco Pivetta wrote:
Actually, having the properties shown even if virtual allows us to
access them in a reflection-ish manner without doing dangerous
assumptions like "does the setter/getter exist"?
The fact that the property is virtual is very useful, even though in
On Jan 23, 2013, at 1:23 PM, Steve Clay wrote:
> First of all, I think the functionality provided by Clint and Nikita's RFC
> [1] is in demand and would be an asset to PHP, but I also think it can
> repackaged more simply.
>
> People are comparing the RFC to C# [2], but while they look similar
On 1/23/2013 8:31 AM, Sherif Ramadan wrote:
Except that everything that's proposed here is possible today with __get,
__set, __isset and __unset. So already today you can't assume that a
property is a "variable". In fact, you could build something like this
using __get, etc extremely dirty:
cla
On Jan 22, 2013, at 6:00 PM, Christopher Jones
wrote:
> On 01/22/2013 01:27 PM, Clint Priest wrote:
>> In terms of cost of maintenance, I was under the impression that
>> since I wrote it, I would be maintaining it which is why I applied
>> for and you approved a VCS acc
On 1/22/2013 9:24 AM, Levi Morrison wrote:
For those that have voted against this proposal, are there any
clarifications that can be made or questions answered?
I can say that this bit is particularly confusing:
public $foo {}
My understanding that this code will not emit any warnings whe
On 1/22/2013 11:20 AM, Rasmus Lerdorf wrote:
On 01/22/2013 03:18 AM, Clint Priest wrote:
For those that have voted against this proposal, are there any
clarifications that can be made or questions answered?
There seems to be a lot of userland support for this proposal from
people who don&#
On 1/22/2013 6:55 AM, Marco Pivetta wrote:
@Lester your explanation simply exposes the fact that your resources to
upgrade to newer technologies are insufficient. This doesn't mean that
newer technologies don't have to exist.
And no, it won't be possible to fix all bugs/flaws before getting a n
On 1/17/2013 12:20 PM, Clint Priest wrote:
I'm happy to say that Property Accessors is ready for a vote for
inclusion in 5.5 release.
Nikita and I (as well as Stas a bit) have all been working hard to
make this happen for 5.5, voting and the specifications are here:
https://wiki.ph
On 1/20/2013 3:11 PM, Gordon Oheim wrote:
Am 17.01.2013 19:20, schrieb Clint Priest:
I'm happy to say that Property Accessors is ready for a vote for
inclusion in 5.5 release.
Nikita and I (as well as Stas a bit) have all been working hard to make
this happen for 5.5, voting an
On 1/21/2013 12:36 PM, Richard Quadling wrote:
Hello.
This may have already been covered, so apologies ...
With https://wiki.php.net/rfc/propertygetsetsyntax-v1.2#references,
the return by reference is handled by the use of &get{}.
How about pass-by-reference for set{}?
It works, it was simpl
On 1/20/2013 9:26 AM, Nikita Popov wrote:
I now added a patch for this proposal: https://gist.github.com/4579298 (For
more detailed individual commits see here:
https://github.com/nikic/php-src/commits/alternativeSyntax)
One thing I hadn't noticed is that the proposal was to move the
typehint,
On 1/20/2013 7:35 AM, Sherif Ramadan wrote:
Now $surface shows us the following from var_dump
object(surface)#1 (3) {
["area"]=>
NULL
["width"]=>
int(4)
["height"]=>
int(2)
}
Sounds like a reasonable approach to me... var_dump()
1) Should not invoke the getters..
2) Should ind
On 1/17/2013 4:24 PM, Steve Clay wrote:
> https://wiki.php.net/rfc/propertygetsetsyntax-v1.2#voting
I'll say my peace on this. This is a very good implementation, and as
long as authors use accessors that depend on a separate property for
storage (like other langs require), everything will be
I'm happy to say that Property Accessors is ready for a vote for
inclusion in 5.5 release.
Nikita and I (as well as Stas a bit) have all been working hard to make
this happen for 5.5, voting and the specifications are here:
https://wiki.php.net/rfc/propertygetsetsyntax-v1.2#voting
Thanks,
-
On 1/13/2013 8:01 AM, Mark wrote:
I'm guessing this RFC won't make it in PHP 5.5? Too bad since it did
seem like a very nice feature to have.
I don't know if it is very helpful but posting nevertheless. I'm a
C++/Qt/QML/PHP developer and for me the proposed syntax in the v1.2
document makes per
Fix bugs, develop features and contribute to the core.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 1/12/2013 11:46 AM, Alexey Zakhlestin wrote:
There is a function for this: http://docs.php.net/array_combine
Nobody ever knows that one, I use it frequently, so useful.
--
-Clint
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
My .02 cents here...
I'm used to array_pluck(), even when I first saw it I was like WTH is
that? When you read the description though, 'plucking' is a verb which
describes the action the function is taking, while column is a noun and
does not describe the action the function is taking.
In f
That is seriously funny
On Jan 11, 2013, at 11:35 PM, Levi Morrison wrote:
>> Can we re-write PHP with PHP? ;)
>
> Anthony and Nikita are already on it: https://github.com/ircmaxell/PHPPHP
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.ph
On 1/11/2013 1:17 PM, Stas Malyshev wrote:
Hi!
A function that is related to a zend_function struct could be placed
anywhere, in any file and can be named in any way. Finding it is like
looking for a needle in a haystack, then you add macros.
You can do macros in C++ too, and you can have de
ly need.
Even so, C++ is not the only object oriented language out there.
-Clint
On 1/11/2013 12:35 AM, Pierre Joye wrote:
No. C++ is horrible. Very good read:
http://damienkatz.net/2013/01/the_unreasonable_effectiveness_of_c.html
On Jan 11, 2013 5:06 AM, "Clint Priest" wrote:
I can't disagree with some of your sentiments, that new things are being
developed while there are some "old things" that are incomplete or in
dis-repair.
Unfortunately, PHP being developed as it is, there are only so many
people able to work on the core.
My own story with php-core was like
Oooh, a rewrite? Can we write it in an object oriented language this
time? Please? Pretty Please???
:D
On 1/10/2013 9:49 PM, guilhermebla...@gmail.com wrote:
Stas,
I totally agree and Pierrick and I faced all these problems during the
creation of patch.
If PHP doesn't all have support req
On 1/10/2013 6:57 PM, Nikita Popov wrote:
Even more generic, we just could use existing ReflectionProperty like
this (this is standard API, no changes needed):
(new ReflectionProperty(get_parent_class(),
'foo'))->setValue($this, $val);
Yes, this is even more long-winded, that'
This version of annotations (attributes?) is much more interesting than
the most recent version, but I could see this syntax as being a problem
if it were allowed to apply to plain functions because then the parser
would have difficulty distinguishing from an array. I suppose the same
could be
I was just looking into C# attributes at the time since I had used them
in the past.
It was a loose translation to something for php from the example on this
page:
http://msdn.microsoft.com/en-us/library/system.componentmodel.dataannotations.stringlengthattribute.aspx
In essence the example w
Just a thought here, but perhaps what PHP needs now is a working group
that works together to do some basic management of PHP as a language,
take into account what the users are wanting, talking about, requesting
and setting a vision and direction and make plans for what will and
won't and when
We should probably be referring to this type of syntax as attributes
rather than annotations since annotations are currently defined in
docblock comments and are recognized by certain software and utilities.
Whereas annotations have no effect on compilation or at runtime,
attributes do have th
Just starting a new thread here to discuss true annotations vs a
DocBlock Parser:
RFC Referenced:
https://wiki.php.net/rfc/annotations
On 1/9/2013 2:09 AM, Peter Cowburn wrote:
On 9 January 2013 01:08, Rasmus Schultz wrote:
I've started working on a new proposal, but I'm getting hung up on
If we had true annotations, its certainly something the engine could put to
use... See my previous post in this thread.
-Clint
On Jan 8, 2013, at 7:38 PM, Rasmus Schultz wrote:
> To summarize:
>
> A native implementation of PHP-DOC block parser for run-time purposes
> (annotation libraries)
Would this 1 or 2 year period begin from release date of 5.3 or as of around
now/vote?
-Clint
On Jan 8, 2013, at 4:00 AM, Pierre Joye wrote:
> On Tue, Jan 8, 2013 at 10:48 AM, Kris Craig wrote:
>
>> Would a voting option to tie it to the release of a future PHP version,
>> rather than a fixe
Just a thought on this, some other languages support attributes which is
similar but could also allow the engine to use them for things. As a quick
example (roughly based on what I've seen in c#) but applied to PHP use case:
class a {
[$date(Nullable)]
public function foo(DateTime $date)
-Clint
On Jan 6, 2013, at 5:11 PM, Sebastian Krebs wrote:
> 2013/1/6 Yahav Gindi Bar
>
>> On Mon, Jan 7, 2013 at 12:41 AM, Marco Pivetta wrote:
>>
>>>
>>> I think that our work is to isolate each annotation so it'll be easy to
access, then, it'll be easy enough to write the code that
2 10:37 PM, Clint Priest wrote:
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)) {
then it adds the evil's listed.
-Clint
On 1/5/2013 3:03 PM, Steve Clay wrote:
On 1/5/13 2:05 PM, Clint Priest wrote:
I like the alternate idea here, but I'm not sure what advantage it
has over the current
situation?
See the "Pros" I listed. The primary being a clear differe
+1 from me as well.
On 1/4/2013 8:41 AM, Nikita Popov wrote:
Hi internals!
I already brought this up before, but I think the discussion at that time
was not very constructive and largely off-topic, so I'm bringing it up
again. To make sure everything is clear I wrote an RFC document:
https://w
I like the alternate idea here, but I'm not sure what advantage it has
over the current situation?
This line of reasoning revealed a difference between what your verbiage
suggestion from a few days ago suggests and what i
On 1/4/2013 4:29 PM, Stas Malyshev wrote:
Hi!
This shouldn't be an issue because it is not possible to set the
property without going through the setter, which would be a type hinted
accessor function.
It is possible, if this property's guard is set. Since guard works for
all code called from
Agreed. Some people may actually be using $parent as a variable name,
not difficult to imagine.
So far parent->foo seems to be the answer.
-Clint
On 1/4/2013 4:23 PM, Stas Malyshev wrote:
Hi!
One other possible alternative would be to treat parent "like a variable..."
$parent->foo
That w
parent "like a variable..."
$parent->foo
On 1/4/2013 5:09 AM, Clint Priest wrote:
Speaking of which, parent::foo ( with :: but no $) might work as well, almost
*any* character change could work...
parent:::$foo
parent:$foo
parent->$foo
parent->foo
parent.$foo
parent.foo
I f
This shouldn't be an issue because it is not possible to set the
property without going through the setter, which would be a type hinted
accessor function.
Ergo, an attempt to set the value to an invalid value would cause a
fatal error and thus the setter would not be able to then set it to th
Speaking of which, parent::foo ( with :: but no $) might work as well, almost
*any* character change could work...
parent:::$foo
parent:$foo
parent->$foo
parent->foo
parent.$foo
parent.foo
I favor having the $ in some solution though...
-Clint
On Jan 4, 2013, at 5:04 AM, Clint Priest
Missed that bit... I think that would add two bits of inconsistency though...
(Without the $)
-Clint
On Jan 4, 2013, at 1:18 AM, Stas Malyshev wrote:
> Hi!
>
>> A recent suggestion from Stas is to use parent->$foo (note the use of ->
>> rather than ::)
>
> I actually proposed parent->foo.
I favor the proposed solution as it provides
for the most flexibility, it would allow sub-classes to re-define a
guarded property as a traditional property, or keep it as a guarded
property (modifying the getter, adding a setter, etc).
On 1/2/2013 5:36 AM, Clint Priest wrote:
Here is the updat
anyone can think of any other way to solve this such that
parent::$foo could work, I'm all ears but I'm out of ideas on this one
and I think Stas's idea is just fine.
On 1/2/2013 5:36 AM, Clint Priest wrote:
Here is the updated RFC incorporating the feedback from previous
rounds
Not really sure what to say about this, we can either guard against
recursion or not, I see
no reason *not* to guard against recursion except that it could allow
unauthorized direct
access when the guard is active.
I guess a third option could be that if the property is attempted to be
acces
On 1/3/2013 9:33 AM, Steve Clay wrote:
On 1/3/13 5:58 AM, Clint Priest wrote:
class Foo {
public $bar = 2 {
get;
set;
}
}
Consider properties not based on shadowed values:
class Foo {
private $realbar;
public $bar = 2 {
get { return $this
On 1/3/2013 8:21 AM, Steve Clay wrote:
On 1/3/13 1:48 AM, Stas Malyshev wrote:
class SuperDate {
private $date {
get;
set(DateTime $x) { $this->date = $x; $this->timestamp =
$x->getTimestamp();
}
private $timestamp {
get;
set($t) { $t = (int)$t; $this
__METHOD__ = ".__METHOD__.PHP_EOL;
return 5;
}
}
}
$o= new a();
echo $o->Foo;
Outputs:
Getting $Foo, __FUNCTION__ = __getFoo, __METHOD__ = a::__getFoo
5
I will add to the RFC that __FUNCTION__ and __METHOD__ work as expected.
On 1/2/2013 3:08 PM, Clint Priest wro
On 1/3/2013 12:48 AM, Stas Malyshev wrote:
Hi!
Within get: $this->Hours can read the underlying property but not write
to it, if it attempts to write, that write would go through the setter.
Within set: $this->Hours = 1 can write to the underlying property but a
read of the property would go t
-core/git/trunk-accessor/cpriest/php/quick2.php on line 9
Good catch on that one.
On 1/2/2013 11:52 PM, Steve Clay wrote:
On Jan 2, 2013, at 10:24 PM, Clint Priest wrote:
I've updated the Shadowing section of the RFC which I hope clears this up, it
also includes a slightly modified versi
ter.
I've updated the Shadowing section of the RFC which I hope clears this
up, it also includes a slightly modified version of your example at the
bottom with comments.
More comments below:
On 1/2/2013 6:28 PM, Steve Clay wrote:
On 1/2/13 6:08 PM, Clint Priest wrote:
Sorry, there was a
On 1/2/2013 4:18 PM, Steve Clay wrote:
On 1/2/13 4:18 PM, Clint Priest wrote:
Omitting isset/unset has the same effect as declaring it without a
body. This is
described in the RFC under Automatic Implementations with this line:
Note that isset/unset implementations will always be provided
n 2, 2013 at 6:36 AM, Clint Priest wrote:
Here is the updated RFC incorporating the feedback from previous rounds of
discussion.
https://wiki.php.net/rfc/**propertynot
getsetsyntax-v1.2<https://wiki.php.net/rfc/propertygetsetsyntax-v1.2>
I'm posting it for final review so I can move to
On 1/2/2013 11:08 AM, Steve Clay wrote:
A few remaining questions. The RFC makes it clear that
ReflectionClass::getMethods() does not return internal method names
like __setSeconds.
1. Are these names visible via get_class_methods() / method_exists() /
is_callable()?
This is the only remaining
Here is the updated RFC incorporating the feedback from previous rounds
of discussion.
https://wiki.php.net/rfc/propertygetsetsyntax-v1.2
I'm posting it for final review so I can move to voting on Jan 7th.
Please note that the current fork is not quite up-to-date with the RFC
but will be with
Can anyone who has an interest in this project please review over the
"Current Consensus Changes" section of this document:
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented/change-requests
Lets hear if there are any other concerns, otherwise in the next couple
of days I will integr
kita, you and Stas are the two most diametrically opposed on this
issue, would you please hash it out and let me know? You all know my
position on what I think it should do and I'd just like this to get
resolved.
-Clint
On 11/14/2012 9:35 AM, Nikita Popov wrote:
On Wed, Nov 14, 2012 at
*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
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
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)
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
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
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
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
: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:/
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
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'
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
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
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 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 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
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
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
1 - 100 of 192 matches
Mail list logo
