[PHP-DEV] Regarding BC bugs fixes and XKCD
I'm sure many, if not all of you have seen this already. http://xkcd.com/1172/ It sounds awfully familiar to PHP Internal's attitude toward BC considerations for bug fixes, and perhaps offers some (albeit humorous) insight into why some things just need to be fixed.
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
On 10/8/12 1:07 PM, Denis Portnov wrote:
08.10.2012 15:52, Clint Priest пишет:
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); }
}
Hi Clint,
I've noticed some magic variable '$value' is introduced. And except
for superglobals I guess there is no such thing in PHP, so it looks
bit puzzling to me. I'd suggest on of the following:
- setter resambles setter method, wich also allows typehinting
public $Hours {
set ($value) { $this-Seconds = $value * 3600; }
}
public $Hours {
set (DateTime $dateTime) { $this-Seconds =
$dateTime-getTimestamp(); }
}
This seems like the cleanest method, in my opinion. Javascript does this
for object prototypes:
http://ejohn.org/blog/javascript-getters-and-setters/
What do you think?
Thanks
Denis
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Generators
On 8/13/12 9:09 AM, Nikita Popov wrote: On Sun, Aug 12, 2012 at 10:08 PM, Brian Moon br...@moonspot.net wrote: Also, not allowing rewinding is unintuitive for something that is an iterator in PHP. If I can foreach() it and I can call next() on it, I expect to be able to reset() it as well. IMO, you would need to issue a FATAL PHP error if that simply is not allowed. Or you have to have a second syntax for what to do in that case. At that point, you are implementing Iterator. Currently I'm planning to implement the following behavior for rewind(): * If before first yield: Resume to first yield (this priming behavior is common to all the Iterator methods) * At first yield: No-op * After first yield: Recoverable fatal error So this would allow you to call -rewind() after creating the generator, but will throw an error if you try to do so later. My perspective is that generators are intended to generate and yield a result, not so much to iterate over a known set of results. Thus, the results not really being known, there is nothing to rewind to. Rewinding would also presumably require more state control, or keeping track of previous results, and defeat the memory advantages of generators. Perhaps this is erroneous? That said, rewind() should behave consistently. I don't feel it makes sense to have rewind() succeed at one point, and fail at another. It would only cause confusion when not familiar with the behavior. Either allow it, or don't. Not both. Thanks, Aaron Holmes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Generators
On 8/14/12 10:36 AM, Stas Malyshev wrote: Hi! That said, rewind() should behave consistently. I don't feel it makes sense to have rewind() succeed at one point, and fail at another. It would only cause confusion when not familiar with the behavior. Either allow it, or don't. Not both. It does, since foreach uses rewind. So first rewind should succeed if you want iterators be usable in foreach. OTOH, on something like DB result set, next rewind does not make any sense, if you have non-seekable cursor, since the results consumed are gone and there's no way to get them back (you could rerun the query, but it might have side effects and nobody guarantees you'd get the same result anyway). So it makes sense for the generator to succeed on first rewind but fail on next ones. Note that generators by nature are stateful objects, so it is not unexpected that they would produce different result in different states. Thanks for clarifying. It makes sense now, considering foreach's behavior and the generators statefulness allowing what otherwise seems inconsistent. However, might it make sense to no-op instead of erroring? If generators allow rewind(), it would be unexpected to receive an error for calling it. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [DRAFT] RFC - array_column() function
For what my .02 is worth, I imagine plucking an item out of an array
would not occur to a user-land developer as the proper nomenclature for
extracting all the values from an array with the given key. At worst,
this means many developers simply won't learn about the function and
continue to implement it in user-land.
When array_column was offered as the name, I immediately knew what the
purpose was, before checking the RFC.
On 6/25/2012 12:22 PM, Ben Ramsey wrote:
On 6/25/12 9:44 AM, Matthew Weier O'Phinney wrote:
On 2012-06-23, Stas Malyshev smalys...@sugarcrm.com wrote:
I'm open to changing or aliasing the name to array_pluck(), if others
are in agreement.
I wouldn't know what pluck means here. Column is a clear word with
established meaning. Let's not get too whimsical here.
Nothing whimsical about it at all, Stas. The definition is:
Take hold of (something) and quickly remove it from its place; pick
and synonyms include pull and gather.
As Ralph noted, column is overloaded, as it has connotations dealing
with databases as well as tables, and arrays often represent neither.
I agree with Tom and Ralph that we should look at what others are
doing and pick a similar name. After searching on pluck, though, I'm
getting mixed results on how pluck is used:
In Rails, it looks like pluck is used for the purpose that I've
created array_column, but it's used with ActiveRecord as a way to pull
a column of results from the database (much like
PDOStatement::fetchColumn). See here:
https://github.com/rails/rails/commit/a382d60f6abc94b6a965525872f858e48abc00de
However, in Prototype.js and Underscore.js, pluck seems behave more
like array_map() in PHP:
http://api.prototypejs.org/language/Enumerable/prototype/pluck/
http://documentcloud.github.com/underscore/#pluck
Nevertheless, it would technically have the same effect as the
column functionality, since calling that method/property in
Javascript simply returns the value of the property or result of the
method call.
Also, the Python community has recently discussed adding pluck for lists:
https://groups.google.com/forum/?fromgroups#!topic/python-ideas/p9qtUzg9zsk
It looks like they already have some functionality that implements
similar behavior, though:
stooges=[{'name': 'moe', 'age': 40}, {'name': 'larry', 'age': 50},
{'name': 'curly', 'age': 60}]
names=[guy['name'] for guy in stooges]
print names
['moe', 'larry', 'curly']
array_column/pluck in PHP would do the same:
$names = array_column($stooges, 'name');
If other languages/frameworks/libraries are using pluck to mean
exactly what this implementation means, then I agree with changing the
name to array_pluck, but if pluck also carries meaning similar to
array_map, then I don't want to confuse folks.
-Ben
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [DRAFT] RFC - array_column() function
The name makes sense, but would likely be confused with extract()
http://us3.php.net/extract
On 6/25/2012 5:35 PM, Paul Dragoonis wrote:
What about array_extract ?
On Mon, Jun 25, 2012 at 9:31 PM, Aaron Holmes aa...@aaronholmes.net
mailto:aa...@aaronholmes.net wrote:
For what my .02 is worth, I imagine plucking an item out of an
array would not occur to a user-land developer as the proper
nomenclature for extracting all the values from an array with the
given key. At worst, this means many developers simply won't learn
about the function and continue to implement it in user-land.
When array_column was offered as the name, I immediately knew what
the purpose was, before checking the RFC.
On 6/25/2012 12:22 PM, Ben Ramsey wrote:
On 6/25/12 9:44 AM, Matthew Weier O'Phinney wrote:
On 2012-06-23, Stas Malyshev smalys...@sugarcrm.com
mailto:smalys...@sugarcrm.com wrote:
I'm open to changing or aliasing the name to
array_pluck(), if others
are in agreement.
I wouldn't know what pluck means here. Column is a
clear word with
established meaning. Let's not get too whimsical here.
Nothing whimsical about it at all, Stas. The definition is:
Take hold of (something) and quickly remove it from
its place; pick
and synonyms include pull and gather.
As Ralph noted, column is overloaded, as it has
connotations dealing
with databases as well as tables, and arrays often
represent neither.
I agree with Tom and Ralph that we should look at what others
are doing and pick a similar name. After searching on pluck,
though, I'm getting mixed results on how pluck is used:
In Rails, it looks like pluck is used for the purpose that
I've created array_column, but it's used with ActiveRecord as
a way to pull a column of results from the database (much like
PDOStatement::fetchColumn). See here:
https://github.com/rails/rails/commit/a382d60f6abc94b6a965525872f858e48abc00de
However, in Prototype.js and Underscore.js, pluck seems behave
more like array_map() in PHP:
http://api.prototypejs.org/language/Enumerable/prototype/pluck/
http://documentcloud.github.com/underscore/#pluck
Nevertheless, it would technically have the same effect as the
column functionality, since calling that method/property in
Javascript simply returns the value of the property or result
of the method call.
Also, the Python community has recently discussed adding pluck
for lists:
https://groups.google.com/forum/?fromgroups#!topic/python-ideas/p9qtUzg9zsk
https://groups.google.com/forum/?fromgroups#%21topic/python-ideas/p9qtUzg9zsk
It looks like they already have some functionality that
implements similar behavior, though:
stooges=[{'name': 'moe', 'age': 40}, {'name': 'larry',
'age': 50}, {'name': 'curly', 'age': 60}]
names=[guy['name'] for guy in stooges]
print names
['moe', 'larry', 'curly']
array_column/pluck in PHP would do the same:
$names = array_column($stooges, 'name');
If other languages/frameworks/libraries are using pluck to
mean exactly what this implementation means, then I agree with
changing the name to array_pluck, but if pluck also carries
meaning similar to array_map, then I don't want to confuse folks.
-Ben
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
