Re: [PHP-DEV] '9223372036854775807' == '9223372036854775808'
On 04/13/2012 09:12 AM, Rasmus Lerdorf wrote: On 04/13/2012 09:09 AM, Stas Malyshev wrote: However I think it would make sense not to use this conversion in string comparisons when we know it's lossy - it seems to be outside of the use case for such comparisons and it seems apparent by now that it is hard for people to understand why it works this way. Yup, I agree, if the type juggling loses data we should skip the juggle and do a direct comparison which I think is what Gustavo's patch does. If people explicitly cast things then the cast, even if it is lossy, should happen. -Rasmus Sadly when I proposed this many months ago my post was ignored. :-( Just chiming in to say +1 for this type of operation. This problem was extremely frustrating and took a while to figure out exactly what was going on, as I had wrongly assumed casting to string at the comparison would cause a strcmp. -Matt -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] array_column() function
On 01/11/2013 04:17 PM, Ben Ramsey wrote: I've opened voting for the array_column() function RFC. You can vote at https://wiki.php.net/rfc/array_column#voting Regards, Ben +1 I can't vote, but I support this RFC. This is much, much simpler to use and easier to implement than most other things I've been watching here recently (annotations, list comprehensions), and I work with multiple teams that would definitely benefit from this on a regular basis. That said, I hate function aliases. Can't we have one or the other here, not both? (array_column() vs array_pluck()) -Matt -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] array_column() function
Hi, On 01/12/2013 07:34 AM, Ben Ramsey wrote: 2) Developers coming from other languages (Ruby, JavaScript, etc.) will instantly recognize array_pluck(). It's what they'll be looking for to do the same thing, but they won't be looking for array_column(). -Ben When I have to write JavaScript (for example), I end up doing google searches like "javascript php array_keys" and always find what I'm looking for without a problem. I really think the alias just adds confusion. Clint's argument for "pluck" being a verb and "column" being a noun makes some sense to me, however "plucking" would imply, to me, that the data is being removed from the source, as opposed to copied from it. As google says: "Pluck: Take hold of (something) and quickly remove it from its place". Also, "array_column" is certainly consistent with other function names in PHP (array_keys(), values(), key(), etc.), which also refer to a set of data within the array data structure, whereas "pluck" sounds very much like a carryover from Ruby and Prototype. -Matt -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] array_column() function
On 01/14/2013 02:19 PM, Lars Strojny wrote: Hi Ben, Am 14.01.2013 um 23:16 schrieb Pierre Joye : [...] Up to you, but I'd to suggest again to re do the vote and add the naming option, easy, clear, open. I was one of the people changing from yes to no because of the name. I like the functionality but I prefer no new array function over one with yet another strange name. cu, Lars You'd rather the new method misuse the meaning of the word "pluck" over following an established convention within it's own environment that is meaningful? If it is called "array_pluck" it should remove the data in question from the original array. (I'm not saying that is a desirable feature here, I'm just saying that makes more sense based on the meaning of the name you seem to prefer.) If there's a problem with the array functions not being verbs (which, personally, I don't think is a huge issue as long as it is consistent), that should be addressed for the array functions as an entire set-- not for one particular one. Re: the vote: There is no point in redoing the vote at this point. If the vote does not pass as it is, that means either the community doesn't support the new feature or they don't support the proposed function name. It's obvious, based on the current vote results, that the community does support the feature, so it is simply a matter of issuing a second vote if this one fails. -Matt -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] array_column() function
On 01/14/2013 10:12 PM, Herman Radtke wrote: If it is called "array_pluck" it should remove the data in question from the original array. (I'm not saying that is a desirable feature here, I'm just saying that makes more sense based on the meaning of the name you seem to prefer.) Why do you think pluck is destructive? In most examples I have come across it merely 'plucks' a certain key from a dictionary and does so in a way that does not modify the original dictionary. Sources: Underscore.js - http://documentcloud.github.com/underscore/#pluck Rails - http://apidock.com/rails/ActiveRecord/Calculations/pluck Python example: http://stackoverflow.com/questions/9816545/pluck-in-python Sources: 1. google:"define: pluck" "Take hold of (something) and quickly *remove* it from it's place" 2. http://www.merriam-webster.com/dictionary/pluck "to pull or *pick* off or *out*" 3. http://www.thefreedictionary.com/pluck "To *remove* or detach ..." Emphasis added. The connotation of the word is that something is *removed* from it's original place. Just because other languages/frameworks have made a poor naming choices doesn't mean PHP should too. In this case, there is already an alternatively proposed method name which is more obvious way to name the method that fits within the established PHP conventions. I'm picky about naming things. :-) -Matt -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Method check - Can someone create a RFC for it?
On 03/20/2013 11:43 AM, Carlos Rodrigues wrote: Like Mike emaild me, i can just change my code to something like $obj->getImage()->getUrl(), where getImage() will return a mock object with getUrl() returning an empty string. But my request here is not about this case only. Imagine you have a web page with 3 blocks of information. Let's say "news", "partners" and "blog". Now if for some reason you didn't code it right, you might get a fatal error in one of these "blocks". I'd love to have a way to try/catch these blocks, Currently i can only do this using ajax, or running shell exec "php block.php" for each one. If we could catch fatal errors, or at least the "Call to a member function on a non-object", we could have this code in our Zend Framework implementations, wrapping each view in a try/catch, and showing a "error, sorry", in case the view has errors. - Carlos Carlos, You should take a look at the other thread that's been in the internals group over the last day or so. There is an effort to see cases like this become E_RECOVERABLE_ERRORs, which I think would address what you're really looking for. (In fact, this particular error is mentioned first in that thread.) But I would argue that, while this is a change I support, this is not a substitute for proper testing prior to code deployment (as others have pointed out). -Matt -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator
Hello all,
First post here; been watching for a while though.
IMHO:
1) Implicit isset() checks in ?: would be bad. This would not
"silently improve not-so-well written code"; In fact it would make
not-so-well written code more difficult to debug. I can't count the
number of times I've run across components that are acting oddly
because somebody wrote them to ignore the fact that they're not
receiving some required parameter. At least with the current
functionality of ?: we get a warning. If the collective decision were
to implement this, could it at least have a setting to force it to
function how it does currently?
2) A shorthand assignment operator would be handy. I like the suggestion of ??=
where:
$var ??= $default;
is shorthand for
if( !isset($var) ) $var = $default;
Or, maybe similar to C#
$var = $var ?? $default;
(Correct me if I'm using this syntax incorrectly)
This would provide a clean way to set defaults for unset vars but
would make it easy to find blocks of code that are using unset vars
with the ternary operator.
-Matt
On Fri, Apr 8, 2011 at 10:45 AM, Martin Scotta wrote:
> I just feels that !empty($arr['key']) or isset($arr['key']) do not express
> the real meaning, instead I would choose to write array_key_exists('key',
> $arr). It may be slower but it clearly express what I meant.
>
> Regarding the operators, I believe they will do more harm than good.
> To check if a variable was already defined is a bad programing habit, these
> operators will encourage that kind of things
>
> In the other hand, the isset check inside the condition ?: would silently
> improve not-so-well written code, and could be a good feature for the lang.
>
> Martin Scotta
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] == Comparison type juggling
I'm sure this has probably been covered here in the past, but I've been unable to find a good way to search for it, so I'll just ask. if( '2011020402421730' === '20110204024217300264' ) echo 'BAD'; else echo 'GOOD'; results in "GOOD" being echoed. However, if( '2011020402421730' == '20110204024217300264' ) echo 'BAD'; else echo 'GOOD'; results in "BAD" being echoed. We guessed that probably the strings were both being converted to ints for the comparison (even on a 64-bit platform 20-digit ints are too large), and indeed the documentation says that "If you compare a number with a string or the comparison involves numerical strings, then each string is converted to a number and the comparison performed numerically." My questions are: 1) What is the advantage to converting both strings to ints to compare them? We have code that compares values for updating in a database, and in this case we were explicitly treating the data as strings, but don't always do so. It was very non-obvious to us that comparing a string-type to a string-type results in the type translation when using ==. It seems counter-productive to have to do: if( (string) $a === (string) $b ) . in every circumstance where $a and $b are be strings representing very large integers. To be clear, I'm referring specifically to circumstances where the type of the objects on both sides of the == comparison are the same. (Maybe int-strings should be a special case, or perhaps this should apply to any object type?) 2) The documentation (http://www.php.net/manual/en/language.operators.comparison.php) only mentions type juggling for ==, !=, and <>, but not greater-than or less-than comparisons. Does this happen with those as well? (If so, I think it could be helpful to have the documentation show this.) 3) If the expected/desired behavior is really to have both strings converted to ints to do the comparison, it would make sense to me to have a "loss of precision" warning- or something to that effect- when the int exceeds the limits of PHP_INT_SIZE-byte ints. However, other than backward compatibility, I have been unable to think of a reason why two strings containing string-representations of ints should be converted for the comparison-- especially with ==. Thanks for your time everybody, Matt -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] DOMNode::getAttribute()
Hello,
I discovered today that the DOMNode::getAttribute() function (which is
undocumented on the php site) returns an empty string if the requested
attribute doesn't exist in the node.
>From the source:
if (value == NULL) {
RETURN_EMPTY_STRING();
} else {
RETVAL_STRING((char *)value, 1);
xmlFree(value);
}
Seems to me that it should return NULL. (That's what libxml does, apparently.)
Does anyone know of a particular reason it returns an empty string instead?
Does anyone know of a particular reason it is not documented?
(I'd be happy to document and provide the ridiculously simple patch of
returning NULL...)
Thanks,
-Matt
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fix for #53727 (is_subclass_of resolution with interfaces)
Seems odd to me that is_subclass_of returns true for interfaces... I never realized that before. Personally I would prefer a separate method to check for interfaces, since they aren't really classes (at least in my head), but I suppose that would break BC. (I've always wanted a method for checking if a class implements an interface.) So, maybe this patch makes sense to me, and some additional method for checking only interfaces would be nice? (I can't think of a good name for such a method.) Thoughts? -Matt On Jun 29, 2011 5:26 PM, "Ralph Schindler" wrote:
Re: [PHP-DEV] Fix for #53727 (is_subclass_of resolution with interfaces)
Not like class_implements(), since that requires processing the returned array... Rather something that would function similarly to is_subclass_of() (in that it returns a bool, not an array), but for interfaces. I seem to run into a need for that on a fairly regular basis. (when I first found class_implements() this is what I thought it did before reading the docs) -matt On Jun 30, 2011 12:46 AM, "David Muir" wrote: > On 30/06/11 11:13, Matt Pelmear wrote: >> Seems odd to me that is_subclass_of returns true for interfaces... I never >> realized that before. >> >> Personally I would prefer a separate method to check for interfaces, since >> they aren't really classes (at least in my head), but I suppose that would >> break BC. (I've always wanted a method for checking if a class implements an >> interface.) >> So, maybe this patch makes sense to me, and some additional method for >> checking only interfaces would be nice? (I can't think of a good name for >> such a method.) Thoughts? >> >> -Matt >> On Jun 29, 2011 5:26 PM, "Ralph Schindler" wrote: >> > > As in class_implements() (shown in Ralph's example)? > > David > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
