Re: [PHP-DEV] [RFC] Propety Accessors v1.1
Clint Priest wrote:
I certainly would not want to push through the door a low quality solution, I would never
do that, but I have been working on this project myself for a year and each time I come
back, having addressed the concerns of the last batch of opinions there are a whole new
set of concerns. It is indeed part of the problem with a project such as this, there is
no head to make a decision, only numerous opinions, none of which come to a
consensus.
Perhaps it is an aspect of the medium of using email for this purpose but it really goes
in every direction at once very quickly and nothing is really ever decided,
it's quite frustrating.
In the end, I just want everyone to come to a consensus on what this should be
and I will go and finish it and be done with it. The original property get/set
RFC has been around for over 3 years and PHP is one of the few modern languages
that does not have such a feature.
Do all RFC's need to become 'law' ?
While on one had I can see the rational behind not SIMPLY using the object
directly, one of the nicest things in PHP has been the short cut to directly
access and update things. Alright it may not be politically correct in some
peoples mind, but isn't it time to think 'Why was PHP4 so popular?' ... because
it was simple and nothing has changed to stop it doing a job. PHP5 seems to get
more and more complex every day ...
Do we need 'reflection' at all?
Do extra hidden things like $o-__getHours() have any place?
Complexity like public set($value) { ... } just seem obscene?
I could make a case for 'public readonly setting;' where the public view can't
write to 'setting' that just seems a logical progression, but instead of
'strict' mode, how about 'simple' mode and disable anything that is not needed
to simply write code ...
--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Issue with PHP Documentation Server
On Wed, Oct 10, 2012 at 10:50 PM, Murali Krishna Bachu murali_nit...@yahoo.co.in wrote: Hi, Links in PHP Doc page sidebar are pointed to wrong links. They are not accessible. http://in2.php.net/curl_version One of the Sidebar link : http://in2.php.net/203.199.107.5manual/en/function.curl-close.php Can some one check the issue? Should be fixed now. In the future. Please file a bug report or notify php-webmas...@lists.php.net of website related issues. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] stream_get_line behaviour Bug #63240
Em 2012-10-10 15:52, Tjerk Meesters escreveu:
Sent from my iPhone
On 10 Oct, 2012, at 6:39 PM, Nicolai Scheer
nicolai.sch...@gmail.com wrote:
Hi again!
Thanks for your help an comments on the issue.
cataphract commented on the stream_get_line behaviour (returning
false
when used on an empty file) on the bug report page.
I do agree that reading on an empty file can be considered an error
thus returning false, because there's nothing to read.
Unfortunately, and that's why we stumbled upon this in the first
place, feof does not return true when opening an empty file.
I did not have a look at the internals, but my guess is that feof
just
does not return true because no one did a read on the file handle
yet.
To my mind if would be sensible to return true using feof on an
empty
file, so that one does not actually try a read...
That wouldn't be right. Technically the EOF should be discovered, not
deduced from other information like stat(). Also, some streams don't
support reporting an appropriate size.
What do you think?
I second what Mr. Meesters has said. The end-of-file indicator should
be discovered. That's how stdio works, which is what PHP's function is
modeled after. There's nothing wrong about the indicator being set in a
read call that returned no data, be it because the file is empty or
because the read before just happened to read all the data left.
Before some recent bug fixes, the successive return values would depend
somewhat on chance. bool(false) would only be returned after the
end-of-file had been discovered. So if the last read had read all the
data but had not found eof, then the next call would return an empty
string. But if it had (the most common scenario), it would return false.
This ambiguity, which is problematic mostly because stream_get_line()
strips off the delimiter, has been eliminated. The only one left is that
you cannot tell whether the input stream ends with the delimiter or not:
$ php -r '$fd = fopen(php://temp, r+); fwrite($fd, aa);
rewind($fd); var_dump(stream_get_line($fd, 10, MM),
stream_get_line($fd, 10, MM));'
string(2) aa
bool(false)
$ php -r '$fd = fopen(php://temp, r+); fwrite($fd, aaMM);
rewind($fd); var_dump(stream_get_line($fd, 10, MM),
stream_get_line($fd, 10, MM));'
string(2) aa
bool(false)
Finally, what I suggest is that use stream_get_line() in the same way
that's recommended for fgets():
while (($buffer = stream_get_line($handle, 8192, MM)) !== false)
{
if (strlen($buffer) == 8192) {
//You may consider this an error
}
echo $buffer;
}
If you're using non-blocking sockets, stream_get_line() may return
false temporarily. In those cases, you may want to do something like:
//stream_get_line() will return false if the stream is temporarily
out
//of data, even if there's some data buffered, as long that
buffered data
//is less than the maxsize you specify and it doesn't contain the
delimiter
do {
//call stream_select() here to wait to for data
while (($buffer = stream_get_line($handle, 8192, MM)) !==
false) {
if (strlen($buffer) == 8192) {
//You may consider this an error
}
echo $buffer;
}
} while (!feof($handle))
--
Gustavo Lopes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
On Thu, Oct 11, 2012 at 2:35 AM, Clint Priest cpri...@zerocue.com wrote:
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 allowed.
2. Preferred syntax for accessors should be public set($value) { ... }
with no magic $value (with possible type hinting)
3. Automatically implemented get; set; with auto-backing field should be
eliminated as this is not necessary for PHP and is confusing most everyone.
This is actually the most useful for me imho, why is it confusing? It
creates a property that is a pure getter/setter what 90% of the properties
need. It would be a shame to see this go.
4. read-only / write-only keywords, keep them or get rid of them? There
is no directly suitable replacement but I believe a private final set() { }
will take care of it, even though it much more verbose.
+1 for private final. Its already there, why not use it.
5. Error handling for thrown exceptions should be made more appropriate
for accessors
6. The truth of reflection. Should it reveal details internal to how
PHP works on the inside or should it reflect the way PHP presents it as
options?
The Reflection API has to be such, that I can code-generate a stub of the
class just from the Reflection API.That means that we have to have access
to the getter/setter methods of the property, otherwise we couldnt generate
a stub for public $Hours { public set(DateTime $time) { ... }}
Did I miss anything?
I will come up with some way for people to vote on the issues at hand and
we can cast our votes and be done with it, then I will finish the project
and get it out the door.
-Clint
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
(Let me suggest an idea irrelevant. Sorry...)
The performance of getters is critical.
For me the best solution would be a new keyword, equivalent to a var
without write access from outside the class:
class TimePeriod {
*property* $Hours = 1;
public function setHours($h) {
$this-Hours = $h;
}
}
$myTP = new TimePeriod();
echo $myTP-Hours; // 1
$myTP-setHours(3);
echo $myTP-Hours; // 3
$myTP-Hours = 5; // KO. PHP error here
Le 08/10/2012 13:42, Clint Priest a écrit :
As an update, just ran some performance testing:
master
Cycles Direct Getter
__get
v1.4 @ 10/8/20121m .05s.21s
.20s
php 5.5.0-dev
Cycles Direct Getter
__get
v1.4 @ 10/8/20121m .04sn/a
.21s
Performance of property accessors was important to me as I'm sure it will be to
many, on one million cycles of a simple getter, it'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 v1.1
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-implemented
Example Usage:
class TimePeriod {
private $Seconds = 3600;
public $Hours {
get { return $this-Seconds / 3600; }
set { $this-Seconds = $value; }
issethttp://www.php.net/isset { return
issethttp://www.php.net/isset($this-Seconds); }
unsethttp://www.php.net/unset {
unsethttp://www.php.net/unset($this-Seconds); }
}
}
Changes / Updates
* isset/unset accessor functions now implemented (object static
context, auto implementations, etc)
* static accessor now fully functional
* Reference functionality validated, tests written
* All operators have been tested, tests written
* read-only and write-only keywords: Added explanation of reasons for
inclusion at the top of the appropriate RFC section
* Tested for speed, approaches or meets __get() speed.
Internally things have changed quite a bit
* cleaned up and simplified
* had been using 4 to 5 additional fn_flag slots, now down to two
(READ_ONLY and WRITE_ONLY)
* the automatic implementations now compiled internal php code, this
greatly simplified that part of the code and future proofed
it.
The code is available at the url below and is up to date with master, all tests
pass.
https://github.com/cpriest/php-src
I'd like to get this project wrapped up in time to make it to the 5.5 release,
only a few things remain to be completed/updated:
* Check on reflection code written prior to major changes (tests still
pass)
* Add a few more reflection functions that were requested
In total there are 79 tests for this new functionality, if there are any others
that I have missed, please let me know.
-Clint
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
On Oct 11, 2012, at 4:59 AM, Clint Priest cpri...@zerocue.com wrote:
Why is everyone so dead set against read-only and write-only?
I could not disagree more with you on what is pretty and readable.
To me:
public read-only $hours {
get { ... }
}
Is infinitely more readable and understandable than:
public $hours {
get() { ... }
private final set($value) { ... }
}
The latter implies that it can be set within the right context (internally
to the class), which is precisely the opposite of what is desired (read only).
If it can be used on normal properties as well (w/o the overhead of function
calls) then: +1
Otherwise it would not be consistent to introduce it.
On the topic of consistency, could not see any other keyword in php that uses
hyphen in it.
From: Jazzer Dane [mailto:tbprogram...@gmail.com]
Sent: 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 private final get() {} are definitely our best bets. But... from a
logical point of view, I prefer read-only/write-only.
private final get() {} is technically saying it will always return null.
private final set() {} is technically saying that setting doesn't do anything
- but it still works.
But I don't see any sane scenario where someone would want to do the above.
Therefore, it may just be best to use them in place of the currently proposed
read-only/write-only.
On Wed, Oct 10, 2012 at 5:35 PM, Clint Priest
cpri...@zerocue.commailto:cpri...@zerocue.com wrote:
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 allowed.
2. Preferred syntax for accessors should be public set($value) { ... }
with no magic $value (with possible type hinting)
3. Automatically implemented get; set; with auto-backing field should be
eliminated as this is not necessary for PHP and is confusing most everyone.
4. read-only / write-only keywords, keep them or get rid of them? There is
no directly suitable replacement but I believe a private final set() { } will
take care of it, even though it much more verbose.
5. Error handling for thrown exceptions should be made more appropriate for
accessors
6. The truth of reflection. Should it reveal details internal to how PHP
works on the inside or should it reflect the way PHP presents it as options?
Did I miss anything?
I will come up with some way for people to vote on the issues at hand and we
can cast our votes and be done with it, then I will finish the project and
get it out the door.
-Clint
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
2012/10/11 Clint Priest cpri...@zerocue.com
Why is everyone so dead set against read-only and write-only?
my opinion
1.
public read-only $hours {
get { /* .. */ }
set { /* .. */ }
}
And now? That this is even possible is reason enough for me. Especially now
the engine must take care about this inconsistency (over the whole
inheritance tree). It feels unnecessary.
2. This new keyword is unnecessary
3. Don't know, if it's just my, but I find it slightly annoying, that this
discussion even exists. The engine already knows every token, that is
required to implement this RFC, so whats this all about? This way it will
not be ready for 5.5 and I guess not for 5.6 either...
4. It is more readable, ok, but it is not that much and I think it's just
to less to say Lets rewrite everything and make everything more complex
(see 1.) and such!
I could not disagree more with you on what is pretty and readable.
To me:
public read-only $hours {
get { ... }
}
Is infinitely more readable and understandable than:
public $hours {
get() { ... }
private final set($value) { ... }
}
The latter implies that it can be set within the right context
(internally to the class), which is precisely the opposite of what is
desired (read only).
No, it's not the opposite, but only slightly more loosely: It only says It
is 'set'able from within this concrete class, but it is read-only from
_everywhere_ else, what is in most cases that, what is _really_ wanted. If
you don't want to set it, don't set it. It is your class. And for everyone
else, it's really read-only.
From: Jazzer Dane [mailto:tbprogram...@gmail.com]
Sent: 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 private final get() {} are definitely our best bets. But... from a
logical point of view, I prefer read-only/write-only.
private final get() {} is technically saying it will always return null.
private final set() {} is technically saying that setting doesn't do
anything - but it still works.
But I don't see any sane scenario where someone would want to do the
above. Therefore, it may just be best to use them in place of the currently
proposed read-only/write-only.
On Wed, Oct 10, 2012 at 5:35 PM, Clint Priest cpri...@zerocue.commailto:
cpri...@zerocue.com wrote:
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 allowed.
2. Preferred syntax for accessors should be public set($value) { ... }
with no magic $value (with possible type hinting)
3. Automatically implemented get; set; with auto-backing field should be
eliminated as this is not necessary for PHP and is confusing most everyone.
4. read-only / write-only keywords, keep them or get rid of them? There
is no directly suitable replacement but I believe a private final set() { }
will take care of it, even though it much more verbose.
5. Error handling for thrown exceptions should be made more appropriate
for accessors
6. The truth of reflection. Should it reveal details internal to how
PHP works on the inside or should it reflect the way PHP presents it as
options?
Did I miss anything?
I will come up with some way for people to vote on the issues at hand and
we can cast our votes and be done with it, then I will finish the project
and get it out the door.
-Clint
--
github.com/KingCrunch
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
hi,
On Thu, Oct 11, 2012 at 2:16 PM, Sebastian Krebs krebs@gmail.com wrote:
public read-only $hours {
get { /* .. */ }
set { /* .. */ }
}
that should not be possible or it will be too complicated to document
or to use. Combinations of the readonly option and a setter should not
be possible.
Cheers,
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Propety Accessors v1.1
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 Accessors v1.1
hi,
On Thu, Oct 11, 2012 at 2:16 PM, Sebastian Krebs krebs@gmail.com wrote:
public read-only $hours {
get { /* .. */ }
set { /* .. */ }
}
that should not be possible or it will be too complicated to document or to
use. Combinations of the readonly option and a setter
should not be possible.
Cheers,
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:
http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
On 11 October 2012 12:46, Cal c...@icical.net wrote: For me the best solution would be a new keyword, equivalent to a var without write access from outside the class: New keywords should not (will not) be introduced trivially, they can cause massive headaches with backwards compatibility breaks, and should be a last resort only when absolutely necessary. Re-using existing keywords is the most logical solution. (i.e. suggestions such as public get and protected/private set) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
On 10/10/12 10:46 PM, Jazzer Dane wrote:
If at all possible, I'd rather not add extra keywords such as read-only and
write-only to the language. If it's unnecessary than it shouldn't be done -
that's my point of view. The question is thus is read-only necessary?.
The proposal brought up by someone else was using
private final set($value) {}
and
private final get() {}
With no code in-between the braces, the functions are not accessible, not
extensible, and pointless. Thus we could arguably use them as alternatives
to the proposed read/write-only syntax.
But, in my previous emai,l I brought up the fact that this proposal isn't
that logically sound. The above lines of code don't exactly mean that
get/set aren't allowed... but at the same time, I don't know of any
scenarios where a developer would want to use private final get/set wherein
null is always returned or nothing is ever set.
The fact that this proposal is consistent with the language is a plus to
me. But I don't think it's enough - I don't like the logical
inconsistencies it brings.
If I were to vote between the two as to which gets implemented into PHP, I
would probably lean towards read/write-only, but I'm not a fan of either.
In the end, we need it to be logical. Good looking, consistent syntax is
nice, but having something behave even a little bit illogically is not at
all okay.
On Wed, Oct 10, 2012 at 7:59 PM, Clint Priest cpri...@zerocue.com wrote:
Why is everyone so dead set against read-only and write-only?
** **
I could not disagree more with you on what is “pretty” and “readable”.
** **
To me:
** **
public read-only $hours {
get { … }
}
** **
Is infinitely more readable and understandable than:
** **
public $hours {
get() { ... }
private final set($value) { … }
}
** **
The latter implies that it can be “set” within the right context
(internally to the class), which is precisely the opposite of what is
desired (read only).
** **
*From:* Jazzer Dane [mailto:tbprogram...@gmail.com]
*Sent:* 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 private final get() {} are definitely our best bets. But... from a
logical point of view, I prefer read-only/write-only.
private final get() {} is technically saying it will always return null.
private final set() {} is technically saying that setting doesn't do
anything - but it still works.
But I don't see any sane scenario where someone would want to do the
above. Therefore, it may just be best to use them in place of the currently
proposed read-only/write-only.
On Wed, Oct 10, 2012 at 5:35 PM, Clint Priest cpri...@zerocue.com
wrote:
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 allowed.
2. Preferred syntax for accessors should be public set($value) { ... }
with no magic $value (with possible type hinting)
3. Automatically implemented get; set; with auto-backing field should be
eliminated as this is not necessary for PHP and is confusing most everyone.
4. read-only / write-only keywords, keep them or get rid of them? There
is no directly suitable replacement but I believe a private final set() { }
will take care of it, even though it much more verbose.
5. Error handling for thrown exceptions should be made more appropriate
for accessors
6. The truth of reflection. Should it reveal details internal to how
PHP works on the inside or should it reflect the way PHP presents it as
options?
Did I miss anything?
I will come up with some way for people to vote on the issues at hand and
we can cast our votes and be done with it, then I will finish the project
and get it out the door.
-Clint
** **
I suspect this will be unpopular, but is there room in PHP to consider
that the developer will do whatever they want with any classes they
are using?
In an instance where the developer wants to change a property defined as
private, they generally have the option to change the class themselves,
and make it public.
Same with final - if they want to extend a class and overload final
functions, they can change the finality in the overloaded class. Of
course, this is true for private and protected as well.
There is a lot of discussion over read-only, but in the end it ends up
only as a suggestion to the developer using it. Why not just make
set() a no-op, if this is what you want to achieve, and document it as
such? I'm not sure why there is so much talk about
RE: [PHP-DEV] [RFC] Propety Accessors v1.1
Rather than go to the trouble of finding a reasonable way to hold a vote on
these issues, is there anyone against the following changes:
1) Eliminate the ability for an accessor to be called via $o-__getHours(), the
accessor functions will be completely unavailable for use except as property
references ($o-Hours)
2) Change syntax to use public set($value) { }, public get(), etc. (and along
with that means no more magic $value)
2a) If possible, allow for Type Hinting...
3) Eliminate automatically implemented get; set;, no automatic backing field
creation will occur.
4) read-only / write-only keywords will be eliminated
5) Exceptions thrown from accessors will be made more appropriate (I will also
check debug_backtrace information, etc)...
If there isn't anyone against the above changes, I will make the changes to the
RFC and re-present for final agreement...
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
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
allowed.
2. Preferred syntax for accessors should be public set($value) { ... }
with no magic $value (with possible type hinting) 3.
Automatically implemented get; set; with auto-backing field should be
eliminated as this is not necessary for PHP and is confusing
most everyone.
4. read-only / write-only keywords, keep them or get rid of them? There is
no directly suitable replacement but I believe a private
final set() { } will take care of it, even though it much more verbose.
5. Error handling for thrown exceptions should be made more appropriate for
accessors 6. The truth of reflection. Should it reveal
details internal to how PHP works on the inside or should it reflect the way
PHP presents it as options?
Did I miss anything?
I will come up with some way for people to vote on the issues at hand and we
can cast our votes and be done with it, then I will
finish the project and get it out the door.
-Clint
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
I'm in favor of all your points Clint and type hinting would be very valuable
to me. Also, I would favor if reflection does not reveal internals either. If I
am correct, that would require ReflectionClass to have
getPropertyAccessors()/getPropertyAccessor('Hours') method and a new
ReflectionPropertyAccessor class for property accessors.
My main point is regarding the read-only issue. I think that, given that the
problem only arises when inheriting from a class defining a property accessor,
a solution would be not to allow to extend accessor property functions (get(),
set(), isset() and unset()) that are not defined in the parent class.
Otherwise, an error should be raised. Something similar is already implemented
in PHP when overriding a parent method with a different signature. Here, we
would not allow to implement a different signature for property accessors in
the child class. So:
class Timing
{
/* … */
/* set() not defined, setting $Hours is not allowed, $Hours is thus
read-only, everybody should agree with this */
public $Hours {
get() { return $this-seconds / 3600; }
final isset() { return isset($this-seconds); }
unset() { unset($this-seconds); }
}
}
class SpecialTiming extends Timing
{
/** … */
public $Hours {
get() { return $this-seconds / 3600; } // -- OK,
set(TypeHint $value) { $this-seconds = 3600 * $value; } // --
ERROR, set() not defined in parent class
final isset() { return isset($this-seconds); } // -- ERROR,
isset() is final in parent class.
/* unset inherited from parent class */
}
}
Am 11.10.2012 um 21:45 schrieb Clint Priest cpri...@zerocue.com:
Rather than go to the trouble of finding a reasonable way to hold a vote on
these issues, is there anyone against the following changes:
1) Eliminate the ability for an accessor to be called via $o-__getHours(),
the accessor functions will be completely unavailable for use except as
property references ($o-Hours)
2) Change syntax to use public set($value) { }, public get(), etc. (and
along with that means no more magic $value)
2a) If possible, allow for Type Hinting...
3) Eliminate automatically implemented get; set;, no automatic backing field
creation will occur.
4) read-only / write-only keywords will be eliminated
5) Exceptions thrown from accessors will be made more appropriate (I will
also check debug_backtrace information, etc)...
If there isn't anyone against the above changes, I will make the changes to
the RFC and re-present for final agreement...
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
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
allowed.
2. Preferred syntax for accessors should be public set($value) { ... }
with no magic $value (with possible type hinting) 3.
Automatically implemented get; set; with auto-backing field should be
eliminated as this is not necessary for PHP and is confusing
most everyone.
4. read-only / write-only keywords, keep them or get rid of them? There is
no directly suitable replacement but I believe a private
final set() { } will take care of it, even though it much more verbose.
5. Error handling for thrown exceptions should be made more appropriate for
accessors 6. The truth of reflection. Should it reveal
details internal to how PHP works on the inside or should it reflect the way
PHP presents it as options?
Did I miss anything?
I will come up with some way for people to vote on the issues at hand and we
can cast our votes and be done with it, then I will
finish the project and get it out the door.
-Clint
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
2012/10/11 Clint Priest cpri...@zerocue.com
Rather than go to the trouble of finding a reasonable way to hold a vote
on these issues, is there anyone against the following changes:
1) Eliminate the ability for an accessor to be called via
$o-__getHours(), the accessor functions will be completely unavailable for
use except as property references ($o-Hours)
I don't really care, but what were the concrete objections? You can call
__construct() directly too and that is similar ... not useful ^^ Assuming,
that most developers should try to avoid unuseful stuff, wouldn't it be
more complicated to explicitly restrict the access?
2) Change syntax to use public set($value) { }, public get(), etc. (and
along with that means no more magic $value)
2a) If possible, allow for Type Hinting...
3) Eliminate automatically implemented get; set;, no automatic backing
field creation will occur.
4) read-only / write-only keywords will be eliminated
5) Exceptions thrown from accessors will be made more appropriate (I will
also check debug_backtrace information, etc)...
If there isn't anyone against the above changes, I will make the changes
to the RFC and re-present for final agreement...
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
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
allowed.
2. Preferred syntax for accessors should be public set($value) { ...
} with no magic $value (with possible type hinting) 3.
Automatically implemented get; set; with auto-backing field should be
eliminated as this is not necessary for PHP and is confusing
most everyone.
4. read-only / write-only keywords, keep them or get rid of them?
There is no directly suitable replacement but I believe a private
final set() { } will take care of it, even though it much more verbose.
5. Error handling for thrown exceptions should be made more appropriate
for accessors 6. The truth of reflection. Should it reveal
details internal to how PHP works on the inside or should it reflect the
way PHP presents it as options?
Did I miss anything?
I will come up with some way for people to vote on the issues at hand
and we can cast our votes and be done with it, then I will
finish the project and get it out the door.
-Clint
--
github.com/KingCrunch
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 cpri...@zerocue.com
Rather than go to the trouble of finding a reasonable way to hold a vote
on these issues, is there anyone against the following changes:
1) Eliminate the ability for an accessor to be called via
$o-__getHours(), the accessor functions will be completely unavailable for
use except as property references ($o-Hours)
2) Change syntax to use public set($value) { }, public get(), etc. (and
along with that means no more magic $value)
2a) If possible, allow for Type Hinting...
3) Eliminate automatically implemented get; set;, no automatic backing
field creation will occur.
4) read-only / write-only keywords will be eliminated
5) Exceptions thrown from accessors will be made more appropriate (I will
also check debug_backtrace information, etc)...
If there isn't anyone against the above changes, I will make the changes
to the RFC and re-present for final agreement...
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
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
allowed.
2. Preferred syntax for accessors should be public set($value) { ...
} with no magic $value (with possible type hinting) 3.
Automatically implemented get; set; with auto-backing field should be
eliminated as this is not necessary for PHP and is confusing
most everyone.
4. read-only / write-only keywords, keep them or get rid of them?
There is no directly suitable replacement but I believe a private
final set() { } will take care of it, even though it much more verbose.
5. Error handling for thrown exceptions should be made more appropriate
for accessors 6. The truth of reflection. Should it reveal
details internal to how PHP works on the inside or should it reflect the
way PHP presents it as options?
Did I miss anything?
I will come up with some way for people to vote on the issues at hand
and we can cast our votes and be done with it, then I will
finish the project and get it out the door.
-Clint
[PHP-DEV] VCS Account Request: dr0id
PHP Trunk, developing bug fixes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Propety Accessors v1.1
I guess I didn't see any other support for it from others and it is a subset of
what the RFC I am proposing would encompass, did I miss something with your
original email?
From: amaury.bouch...@gmail.com [mailto:amaury.bouch...@gmail.com] On Behalf Of
Amaury Bouchard
Sent: Thursday, October 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 cpri...@zerocue.commailto:cpri...@zerocue.com
Rather than go to the trouble of finding a reasonable way to hold a vote on
these issues, is there anyone against the following changes:
1) Eliminate the ability for an accessor to be called via $o-__getHours(), the
accessor functions will be completely unavailable for use except as property
references ($o-Hours)
2) Change syntax to use public set($value) { }, public get(), etc. (and along
with that means no more magic $value)
2a) If possible, allow for Type Hinting...
3) Eliminate automatically implemented get; set;, no automatic backing field
creation will occur.
4) read-only / write-only keywords will be eliminated
5) Exceptions thrown from accessors will be made more appropriate (I will also
check debug_backtrace information, etc)...
If there isn't anyone against the above changes, I will make the changes to the
RFC and re-present for final agreement...
Or... do ya'll want to vote on the aforementioned changes?
-Original Message-
From: Clint Priest [mailto:cpri...@zerocue.commailto:cpri...@zerocue.com]
Sent: Wednesday, October 10, 2012 7:36 PM
To: internals@lists.php.netmailto:internals@lists.php.net
Subject: RE: [PHP-DEV] [RFC] Propety Accessors v1.1
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
allowed.
2. Preferred syntax for accessors should be public set($value) { ... }
with no magic $value (with possible type hinting) 3.
Automatically implemented get; set; with auto-backing field should be
eliminated as this is not necessary for PHP and is confusing
most everyone.
4. read-only / write-only keywords, keep them or get rid of them? There is
no directly suitable replacement but I believe a private
final set() { } will take care of it, even though it much more verbose.
5. Error handling for thrown exceptions should be made more appropriate for
accessors 6. The truth of reflection. Should it reveal
details internal to how PHP works on the inside or should it reflect the way
PHP presents it as options?
Did I miss anything?
I will come up with some way for people to vote on the issues at hand and we
can cast our votes and be done with it, then I will
finish the project and get it out the door.
-Clint
[PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
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 the final code changes. -Clint
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 cpri...@zerocue.com 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 leave this open for the two week waiting period while I make the final code changes. -Clint
