Re: [PHP-DEV] removing an item from an array
On 16.08.2012, at 0:18, Rasmus Schultz wrote: > How come there is no straight-foward obvious way to simply remove a given > value from an array? Well, this sounds like a reason for creating SplSet class -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] removing an item from an array
On Thu, Aug 16, 2012 at 2:39 AM, Lars Schultz wrote:
> Am 16.08.2012 07:55, schrieb Sherif Ramadan:
>
>> Now your array is something completely different from what you wanted.
>> The solution stated earlier is the most sane one (just using
>> array_keys() with a search value).
>
>
> the array_keys solution is slower (although barely) than my suggested
> array_slice solution but comes up short when looking at the result closely.
> The resulting array won't be properly indexed anymore, but will be a
> numbered hashmap. I am not sure wether PHP keeps an internal state on wether
> an array is a map or a classic array, but when you require indizes to be
> sequential (without gaps) then unset() just won't do. Thus it's not always a
> simple problem.
>
Efficiency is only secondary to effectiveness. Either the
function/implementation does what you want or it doesn't.
Further more, your assumption here that the result is incorrect (or
improperly indexed) is completely baseless and moot. You are making a
bold assumption that I both care about the keys and that I expect them
to be numeric and sequential (why can't I have string keys?). This
would also entail that I depend on keys for order (which is not a
requirement for a PHP Array since all PHP Arrays are
ordered-hashmaps).
$array = (99=>1, 7=>2, 701=>3);
foreach ($array as $v) {
echo "$v\n";
}
/* Output is as expected
1
2
3
*/
unset($array[7]);
foreach ($array as $v) {
echo "$v\n";
}
/* Output is still as expected
1
3
*/
The order of the elements in the array has not been affected by the
keys that index them or the use of unset() in the least. So your
argument holds no merit. If you are depending on the sequence of the
keys to determine the order of your elements you made a huge mistake,
because the array was already designed to store elements in order
regardless of whether you provide a key or not. So you're solving the
wrong problem here.
>
>> I don't wish to degrade anyone's contributions to this thread, but
>> this really is the perfect example of making a lot of fuss over
>> nothing on the mailing list and an example of the kinds of discussion
>> we should be avoiding when there are so many other important problems
>> we can solve.
>
>
> Rasmus' suggestion was very concise and unfussy. I've been wondering the
> same thing for some time. It would make the array-functionset more complete
> and code more explicit. Why should we only talk about major changes and
> additions?
>
>
I never said it was redundant or fussy.
Here you're advocating that you're "for" this feature and yet just a
few posts earlier you explicitly state (and I quote):
"I am not arguing for another array-function (as there are so many already)"
This is exactly the kind of noise I see people making in these types
of threads. On one hand they argue indifference (and yet they're here
making all sorts of claims), and on the other hand they want to argue
for arguments sake (like where they're contradicting themselves like
you have).
On one hand you're saying "It would make the array-functionset more
complete" and on the other hand you're also saying "...there are so
many (array functions) already..."
Which is it?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [VOTE]Call for voting: support use list in foreach
Hi: This feature introduces list() support in foreach constructs(more info can be found here: https://wiki.php.net/rfc/foreachlist). this could make the grammar more consistent, see following example: previous discussion could be found at : http://marc.info/?l=php-internals&m=134277050215818&w=2 please vote for this: https://wiki.php.net/rfc/foreachlist#vote thanks :) -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Combined assignment operator for short ternary
Sent from my iPhone On 18 Aug, 2012, at 5:41 AM, Sebastian Krebs wrote: > Hi, > > Don't know, how complicated this is (and also someone (not me) must implement > it, because I can't :X), but to be in sync with the operators the short > ternary operator should be usable in conjunction with the assignment like the > other binary operators. Don't know, if anybody understands me :D So here is > an example > > // instead of > $foo = $foo ?: 'default'; > // Just > $foo ?:= 'default'; Why not just: $foo ?= 'default'; > > I have many of this "default assigments" and yes: This is just syntactic > sugar. > > Regards, > Sebastian > > -- > 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] Combined assignment operator for short ternary
On 17/08/12 23:41, Sebastian Krebs wrote: > Hi, > > Don't know, how complicated this is (and also someone (not me) must > implement it, because I can't :X), but to be in sync with the > operators the short ternary operator should be usable in conjunction > with the assignment like the other binary operators. Don't know, if > anybody understands me :D So here is an example > > // instead of > $foo = $foo ?: 'default'; > // Just > $foo ?:= 'default'; > > I have many of this "default assigments" and yes: This is just > syntactic sugar. This seems to enter into ASCII art land. $emoticon ?:=( 8) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] re: removing an item from an array
On Fri, Aug 17, 2012 at 11:35 PM, Rasmus Schultz wrote: > Most other languages have more than one collection-type... since PHP has > only the single, hybrid array-type which acts both as a hash and as an > array, something like this ought to be available. > > I don't know why everyone is so eager to jump up and argue against > something this simple, basic and useful. The fact that this is missing is > an oversight - just look at the number of solutions people come up with. > For what? Could we please stop these pseudo-arguments? "simple, basic and useful. The fact that this is missing is an oversight"? Do you have anything to back up these claims? I can't remember to have been in a situation where I wanted to remove a value from an array. Simply because that's a slow operation. When you have to do it you *usually* have chosen the wrong datastructure. And in the cases where you do need it, you can easily do it with array_search. Where is the issue? Also, as I already pointed out, "removing a value from an array" is not well defined. Do you mean to only remove the first occurrence of the value? Only the last? All of them? Do you want to have special functions for all of those? Furthermore, why do you keep coming back to the "There exists more than one solution to this problem" argument? Everything can be done in a large number of ways. And people come up with a lot of ways, depending on the situation. You can output a string with echo, with print, with concatenation, with interpolation, with multi-arg echo, with printf, etc. So sure, there are also multiple ways to remove values from an array. What's the issue with that? Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Combined assignment operator for short ternary
Hi, Don't know, how complicated this is (and also someone (not me) must implement it, because I can't :X), but to be in sync with the operators the short ternary operator should be usable in conjunction with the assignment like the other binary operators. Don't know, if anybody understands me :D So here is an example // instead of $foo = $foo ?: 'default'; // Just $foo ?:= 'default'; I have many of this "default assigments" and yes: This is just syntactic sugar. Regards, Sebastian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] re: removing an item from an array
On 08/17/2012 05:35 PM, Rasmus Schultz wrote: > Most other languages have more than one collection-type... since PHP has > only the single, hybrid array-type which acts both as a hash and as an > array, something like this ought to be available. > > I don't know why everyone is so eager to jump up and argue against > something this simple, basic and useful. The fact that this is missing > is an oversight - just look at the number of solutions people come up > with. For what? > > I want to remove and object from a list. Not an exotic and crazy > requirement, is it? It just isn't the sort of thing that should require > any substantial thinking or typing. > > And it doesn't help make codebases more legible when people come up with > 25 different ways to do it. The problem is that it is a rather unusual thing to do. I don't mean removing an element, that is very common, but you are implying that you know you don't have duplicates and you want a fast way to remove an element by value in that case. To me that means you built your array badly. If the values are unique then they should be the keys, or at least a representation of the value should be the key such that you don't need to scan the entire hash for the element when you need to access it. And removal is just like any other access. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] re: removing an item from an array
Most other languages have more than one collection-type... since PHP has
only the single, hybrid array-type which acts both as a hash and as an
array, something like this ought to be available.
I don't know why everyone is so eager to jump up and argue against
something this simple, basic and useful. The fact that this is missing is
an oversight - just look at the number of solutions people come up with.
For what?
I want to remove and object from a list. Not an exotic and crazy
requirement, is it? It just isn't the sort of thing that should require any
substantial thinking or typing.
And it doesn't help make codebases more legible when people come up with 25
different ways to do it.
On Fri, Aug 17, 2012 at 5:23 PM, Rasmus Lerdorf wrote:
> On 08/17/2012 05:21 PM, Rasmus Schultz wrote:
> >>
> >> if(($key = array_search($del_val, $messages)) !== false) {
> >> unset($messages[$key]);
> >> }
> >>
> >> Nothing horrible here.
> >>
> >
> > I disagree - this is (or should be) a simple, atomic operation...
> > yet, you've got a function-call, an intermediary variable, a boolean
> test,
> > and an unset statement repeating the name of the array you're deleting
> from.
> >
> > This should be a simple statement or function/method-call, and in most
> > other languages it would be...
>
> Really? I can't think of a single language that has a call to remove an
> element by value in a key-value hash. Do you have some examples? What do
> you do with duplicates?
>
> -Rasmus
>
>
Re: [PHP-DEV] re: removing an item from an array
On 08/17/2012 05:21 PM, Rasmus Schultz wrote:
>>
>> if(($key = array_search($del_val, $messages)) !== false) {
>> unset($messages[$key]);
>> }
>>
>> Nothing horrible here.
>>
>
> I disagree - this is (or should be) a simple, atomic operation...
> yet, you've got a function-call, an intermediary variable, a boolean test,
> and an unset statement repeating the name of the array you're deleting from.
>
> This should be a simple statement or function/method-call, and in most
> other languages it would be...
Really? I can't think of a single language that has a call to remove an
element by value in a key-value hash. Do you have some examples? What do
you do with duplicates?
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] re: removing an item from an array
>
> if(($key = array_search($del_val, $messages)) !== false) {
> unset($messages[$key]);
> }
>
> Nothing horrible here.
>
I disagree - this is (or should be) a simple, atomic operation...
yet, you've got a function-call, an intermediary variable, a boolean test,
and an unset statement repeating the name of the array you're deleting from.
This should be a simple statement or function/method-call, and in most
other languages it would be...
Re: [PHP-DEV] Inline typecasting / typehinting for classes and interfaces
On Aug 15, 2012, at 8:33 PM, Nikita Popov wrote: On Wed, Aug 15, 2012 at 8:15 PM, Kris Craig mailto:kris.cr...@gmail.com>> wrote: On Wed, Aug 15, 2012 at 4:48 AM, Anthony Ferrara mailto:ircmax...@gmail.com>>wrote: Stan, On Wed, Aug 15, 2012 at 3:57 AM, Stan Vass mailto:sv_for...@fmethod.com>> wrote: Hi! I agree with you. The one case where this syntax may be very useful is if we want to implement class casting. So introduce a pair of magic methods I do not think we want to implement class casting. I'm not sure how class casting even makes sense - if the object is of one class, how can you just make it into another class by casting? If you mean "casting" actually returns another object of different class, then just make a method for that that returns that object, I do not see how obscuring the purpose of this operation with unobvious syntax would help. The discussion is starting to drift very far from my original proposal. Instead of trying to guess what I mean, can't people just refer to my very simple definitive proposed behavior? My point was that what I posted was the only way that I can see for the original proposal to be useful. Anthony Though I'm clearly in the minority on this, I for one think this proposal does have more merit than is being argued. There seems to be general agreement all around that this would provide a benefit as it pertains to code readability-- Not just by humans, but theoretically by doc/etc parsers as well. This is where we get into arbitrary, subjective territory. To me, that benefit in and of itself is sufficient to warrant this feature. To many of you, it is not enough. The tie-breaker for me is the fact that, though the benefits are modest, there's really no noticeable cost, either. The argument seems to, essentially, break down as follows: "This feature isn't worth our time." "Yes, it is!" "No, it isn't." Every feature has a cost, even if that cost is just maintaining the code. Doing language changes for minority use cases, which already have sensible solutions, doesn't make much sense. Another aspect here is that there is no reasonable syntax for this feature, at least I can't think of one: * The syntax `$foo = (InterfaceName) $container->service` is completely out of question. It looks like a cast, but wouldn't actually do a cast. * Same is to be said about `InterfaceName $foo = $container->service`. This syntax implies that the $foo variable will always be of type InterfaceName, even if it is later reassigned. It's not a sensible syntax for a one time validation * The other three syntaxes that were mentioned were just as unclear. E.g. `$foo = $container->service as InterfaceName` again looks like a strange cast syntax and `$foo = $container->service is InterfaceName` looks like the assignment should evaluate to a boolean (i.e. `is` is some kind of `instanceof`). good points On the other hand, the current ways of accomplishing the same goal are well-established and easy to understand: * Using a docblock: /** @var $foo IntefaceName **/ * Using an assertion: assert($foo instanceof InterfaceName). I think that the assertion is a rather concise and clear way to do this. It is much more obvious than some new and obscure `$foo = (InterfaceName $container->service)` syntax. @Stan: If you make sure you configure your container to injection dependencies and in case of lazy loading inject factories with type hinting in doc istead of passing the [dependency injection] container around as a registry, then you almost don't get this problem at all, and you will avoid introducing container awareness/dependency in your architecture. Only place you will have this original problem though is in the code that gets the first dependency of the execution, but even then you can have Container interface for the most common root dependencies. Like: https://github.com/ezsystems/ezp-next/blob/master/eZ/Publish/API/Container.php Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Phar PGP signature support
Hi all, I'm wondering what the status/plan is for supporting PGP for Phar signatures. So far I've only found a couple of vague references such as on the Phar::setSignatureAlgorithm() manual page: > The signature algorithm must be one of Phar::MD5, Phar::SHA1, Phar::SHA256, > Phar::SHA512, or Phar::PGP (pgp not yet supported and falls back to SHA-1). There's also a brief reference here, http://lxr.php.net/xref/PHP_TRUNK/ext/phar/TODO#42 However, I have not been able to find much else. Perhaps there is an RFC or old ML thread that I'm missing? Any info would be appreciated. Thanks, --- Evan Coury, ZCE http://blog.evan.pro/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
