On 2012-08-16 17:55, Sherif Ramadan wrote:
> That doesn't make any sense. What if the values are present more than
> once? array_flip will cause the keys to be overwritten.
>
Not to mention converting all of the array's elements to strings and/or
integers.
Now your array is something complete
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
>
> This is my favourite way of removing a value:
> $kv = array( 1 => 'a', 2 => 'b', 3 => 'c');
> $vk = array_flip($kv);
> unset($vk['b']);
> $kv = array_flip($vk);
That doesn't make any sense. What if the values are present more than
once? array_flip will cause the keys to be overwritten.
$arra
Am 15.08.2012 22:22, schrieb Stas Malyshev:
Just look at the number of horrible ways people solve this obvious problem:
I see:
if(($key = array_search($del_val, $messages)) !== false) {
unset($messages[$key]);
}
Nothing horrible here.
One thing that should be noted in this case and any s
On Wed, Aug 15, 2012 at 7:59 PM, Morgan L. Owens wrote:
> On 2012-08-16 08:27, Nikita Popov wrote:
>
>> On Wed, Aug 15, 2012 at 10:22 PM, Stas Malyshev
>> wrote:
>>
>>> Hi!
>>>
>>> How come there is no straight-foward obvious way to simply remove a
given
value from an array?
Just
On 2012-08-16 08:27, Nikita Popov wrote:
On Wed, Aug 15, 2012 at 10:22 PM, Stas Malyshev wrote:
Hi!
How come there is no straight-foward obvious way to simply remove a given
value from an array?
Just look at the number of horrible ways people solve this obvious problem:
I see:
if(($key = ar
On Wed, Aug 15, 2012 at 1:35 PM, Kris Craig wrote:
>
>
> On Wed, Aug 15, 2012 at 1:31 PM, Nikita Popov wrote:
>
>> On Wed, Aug 15, 2012 at 10:29 PM, Kris Craig
>> wrote:
>> >>
>> >> Btw, deleting all values (not just the first) is also very easy
>> currently:
>> >>
>> >> foreach (array_keys($arr
On Wed, Aug 15, 2012 at 1:31 PM, Nikita Popov wrote:
> On Wed, Aug 15, 2012 at 10:29 PM, Kris Craig wrote:
> >>
> >> Btw, deleting all values (not just the first) is also very easy
> currently:
> >>
> >> foreach (array_keys($array, $delValue) as $key) {
> >> unset($array[$key]);
> >> }
> >>
On Wed, Aug 15, 2012 at 10:29 PM, Kris Craig wrote:
>>
>> Btw, deleting all values (not just the first) is also very easy currently:
>>
>> foreach (array_keys($array, $delValue) as $key) {
>> unset($array[$key]);
>> }
>>
>
> Even easier still, just do this:
>
> $array_var = array();
It's ofte
>
>
> Btw, deleting all values (not just the first) is also very easy currently:
>
> foreach (array_keys($array, $delValue) as $key) {
> unset($array[$key]);
> }
>
>
Even easier still, just do this:
$array_var = array();
--Kris
On Wed, Aug 15, 2012 at 10:22 PM, Stas Malyshev wrote:
> Hi!
>
>> How come there is no straight-foward obvious way to simply remove a given
>> value from an array?
>
> The same reason there's no simple way to undefine variable whose value
> is 42 without knowing the variable name. Array is a conta
I like that chose 42 for the value. You win, and I completely agree.
On Wed, Aug 15, 2012 at 4:22 PM, Stas Malyshev wrote:
> Hi!
>
> > How come there is no straight-foward obvious way to simply remove a given
> > value from an array?
>
> The same reason there's no simple way to undefine variable
Hi!
> How come there is no straight-foward obvious way to simply remove a given
> value from an array?
The same reason there's no simple way to undefine variable whose value
is 42 without knowing the variable name. Array is a container indexed by
keys, not values. So if you've got just a value, t
How come there is no straight-foward obvious way to simply remove a given
value from an array?
Just look at the number of horrible ways people solve this obvious problem:
http://stackoverflow.com/questions/7225070/php-array-delete-by-value-not-key
Shouldn't we have something simple, like:
a
Giedrius Dubinskas wrote:
On Wed, Aug 15, 2012 at 6:54 PM, Lester Caine wrote:
Giedrius Dubinskas wrote:
My main aim with this suggestion is readability. I'd like to remove
unnecessary noise in code where it doesn't add any value to the
reader. Code is easy to type (especially with good autoc
On Wed, Aug 15, 2012 at 8:15 PM, Kris Craig wrote:
> On Wed, Aug 15, 2012 at 4:48 AM, Anthony Ferrara wrote:
>
>> Stan,
>>
>> On Wed, Aug 15, 2012 at 3:57 AM, Stan Vass wrote:
>>
>> > Hi!
>> >>
>> >> I agree with you. The one case where this syntax may be very useful is
>> if
>> >>> we want to i
On Wed, Aug 15, 2012 at 4:48 AM, Anthony Ferrara wrote:
> Stan,
>
> On Wed, Aug 15, 2012 at 3:57 AM, Stan Vass 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
>
On Wed, Aug 15, 2012 at 6:54 PM, Lester Caine wrote:
> Giedrius Dubinskas wrote:
>>
>> My main aim with this suggestion is readability. I'd like to remove
>> unnecessary noise in code where it doesn't add any value to the
>> reader. Code is easy to type (especially with good autocompletion) but
>>
Giedrius Dubinskas wrote:
My main aim with this suggestion is readability. I'd like to remove
unnecessary noise in code where it doesn't add any value to the
reader. Code is easy to type (especially with good autocompletion) but
it is read more often then typed and I think that is important. Or i
On Wed, Aug 15, 2012 at 4:54 PM, Sebastian Krebs wrote:
> 2012/8/15 Giedrius Dubinskas
>
>> On Wed, Aug 15, 2012 at 2:19 PM, Yahav Gindi Bar
>> wrote:
>> > On Wed, Aug 15, 2012 at 2:09 PM, Paul Dragoonis
>> wrote:
>> >>
>> >> Comments inline.
>> >>
>> >> On Wed, Aug 15, 2012 at 11:59 AM, Giedri
Hi,
This additional "function" seems little bit ... misplaced. :X Why not just
use MyFoo\Bar;
Bar\baz(); // <-- Would be cool, if this trigger an autloader if required
Except, that there is no autoloading everything already works this way.
Regards,
Sebastian
2012/8/15 Giedrius Dubinskas
>
2012/8/15 Giedrius Dubinskas
> On Wed, Aug 15, 2012 at 2:19 PM, Yahav Gindi Bar
> wrote:
> > On Wed, Aug 15, 2012 at 2:09 PM, Paul Dragoonis
> wrote:
> >>
> >> Comments inline.
> >>
> >> On Wed, Aug 15, 2012 at 11:59 AM, Giedrius Dubinskas
> >> wrote:
> >> > Hello Internals!
> >> >
> >> > I'm
Yes that is a very common use case and autoloading functions would
solve that one but my main aim here is readability. And that said I
would also suggest:
use function Namespaced\foo;
foo(); // calls Namespaced\foo();
;-)
--
Giedrius Dubinskas
On Wed, Aug 15, 2012 at 2:26 PM, Sebastian Kre
On Wed, Aug 15, 2012 at 2:19 PM, Yahav Gindi Bar wrote:
> On Wed, Aug 15, 2012 at 2:09 PM, Paul Dragoonis wrote:
>>
>> Comments inline.
>>
>> On Wed, Aug 15, 2012 at 11:59 AM, Giedrius Dubinskas
>> wrote:
>> > Hello Internals!
>> >
>> > I'm just on and off luker here but thought I'll throw in an
Stan,
On Wed, Aug 15, 2012 at 3:57 AM, Stan Vass 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 ho
Hi,
because it fits into the context (even if it's slightly offtopic): Can I
throw in, that I would like to see autoloading for functions? :)
Regards,
Sebastian
2012/8/15 Nikita Popov
> On Wed, Aug 15, 2012 at 12:59 PM, Giedrius Dubinskas
> wrote:
> > Hello Internals!
> >
> > I'm just on and
2012/8/15 Stan Vass
> But "variable" typehints
>> don't serve any such purpose. Actually, one could even say that they
>> don't serve *any* purpose, short of providing the IDE with type
>> information, because your code would work just as well even without
>> the type check. If the type were wron
On Wed, Aug 15, 2012 at 2:09 PM, Paul Dragoonis wrote:
> Comments inline.
>
> On Wed, Aug 15, 2012 at 11:59 AM, Giedrius Dubinskas
> wrote:
> > Hello Internals!
> >
> > I'm just on and off luker here but thought I'll throw in an idea for a
> > feature I'd love to see in PHP: aliasing static meth
On Wed, Aug 15, 2012 at 12:59 PM, Giedrius Dubinskas
wrote:
> Hello Internals!
>
> I'm just on and off luker here but thought I'll throw in an idea for a
> feature I'd love to see in PHP: aliasing static methods.
>
> Syntax would look something like this:
>
> use Namespaced\SomeClass::staticMeth
Comments inline.
On Wed, Aug 15, 2012 at 11:59 AM, Giedrius Dubinskas
wrote:
> Hello Internals!
>
> I'm just on and off luker here but thought I'll throw in an idea for a
> feature I'd love to see in PHP: aliasing static methods.
>
> Syntax would look something like this:
>
> use Namespaced\Som
Hello Internals!
I'm just on and off luker here but thought I'll throw in an idea for a
feature I'd love to see in PHP: aliasing static methods.
Syntax would look something like this:
use Namespaced\SomeClass::staticMethod;
use Some\Foo::bar as fooBar;
staticMethod(); // would call Namesp
Hi,
I know I shouldn't feed the troll, but I want to say this once and for all and
be clear about it.
On 15 August 2012 at 10:32 Lester Caine wrote:
> I am trying to follow all the latest threads on various decorators, casting,
> contracts, iterators, interfaces and the rest but I have to be
On 14 August 2012 at 20:58 Stas Malyshev wrote:
> Hi!
>
> > Simply because your object responds to all the same methods of, for
> > example, the FooInterface, does not make it a FooInterface subtype. It
> > just means that in the "duck typing" sense of the phrase, it can act
> > like a FooInt
On 15 August 2012 18:15, Nikita Popov wrote:
> As already pointed out repeatedly, argument typehints serve the
> purpose of defining an interface. No, they are not required to run the
> code, that's true. But they still serve an important purpose for
> object oriented programming (and, just to mak
On Wed, Aug 15, 2012 at 12:01 PM, Stan Vass wrote:
> Just like with argument typehints.
> Point me to an argument typehint that is required for your code to run.
>
> You and Stas keep giving arguments against argument typehints, which is
> really awkward.
As already pointed out repeatedly, argume
But "variable" typehints
don't serve any such purpose. Actually, one could even say that they
don't serve *any* purpose, short of providing the IDE with type
information, because your code would work just as well even without
the type check. If the type were wrong, it would just throw a fatal
erro
Stas already pointed out that parameter typehints allow you to define
the interface for your method. Return typehints would server a similar
purpose and as such I'd consider them useful. But "variable" typehints
don't serve any such purpose.
I gave an example validating an array of Foo instances
I am trying to follow all the latest threads on various decorators, casting,
contracts, iterators, interfaces and the rest but I have to be honest ... I
simply don't understand the majority of what is being discussed. All right I
don't have to use it, but on the whole I have no problem with any
On Wed, Aug 15, 2012 at 11:17 AM, Stan Vass wrote:
> You're 10 years too late to argue the merits of typehints in PHP.
>
> I am not proposing the introduction of typehints. I'm just saying "we have
> the option to use them in arguments, let's have the options inline too."
> This way we can validat
Hi!
All right, your method accepts an array of objects, instances of Foo. How
do
you enforce this contract?
You are trying to re-invent generics/parametrized types and bolt it onto
PHP. I still don't think it is a good idea - PHP is not a statically
typed language. Just check you array elemen
Hi!
> All right, your method accepts an array of objects, instances of Foo. How do
> you enforce this contract?
You are trying to re-invent generics/parametrized types and bolt it onto
PHP. I still don't think it is a good idea - PHP is not a statically
typed language. Just check you array eleme
Hi!
Let me ask you - do you think the existing PHP typehints are pointless
too?
Do you feel they don't give you enough flexibility? Do you feel they
reinvented a language construct for the purpose of saving the typing of
one
if clause (per argument) (per method) (per class)?
They are not po
On Wed, Aug 15, 2012 at 10:06 AM, Stan Vass wrote:
I'd like to also ask people to read what the intended effect of the
proposal
is instead of going into abstract discussions about how casting one class
to
another doesn't make sense (this is not what's being proposed).
I think you confused ev
Hi!
> Let me ask you - do you think the existing PHP typehints are pointless too?
> Do you feel they don't give you enough flexibility? Do you feel they
> reinvented a language construct for the purpose of saving the typing of one
> if clause (per argument) (per method) (per class)?
They are n
On Wed, Aug 15, 2012 at 10:06 AM, Stan Vass wrote:
> I'd like to also ask people to read what the intended effect of the proposal
> is instead of going into abstract discussions about how casting one class to
> another doesn't make sense (this is not what's being proposed).
I think you confused e
And assignment is a kinda common operation. So I hope you can see what's
wrong with it now.
No I do not. Not every imaginable use case should have dedicated
language construct for it - sometimes it is OK to type 2 lines of code.
Sometimes even 3. This case is well served by existing language syn
Hi!
> And assignment is a kinda common operation. So I hope you can see what's
> wrong with it now.
No I do not. Not every imaginable use case should have dedicated
language construct for it - sometimes it is OK to type 2 lines of code.
Sometimes even 3. This case is well served by existing lang
What's wrong with instanceof? You can then throw fatal error if you
want, it's just two lines:
if(!($foo instanceof Bar)) {
trigger_error(E_USER_ERROR, "Wrong foo!");
}
That's 3 lines on top of the line where you assign the value, and you forgot
the 4th line for the IDE:
-
/* @var $foo
I'd like to also ask people to read what the intended effect of the proposal
is instead of going into abstract discussions about how casting one class to
another doesn't make sense (this is not what's being proposed).
Just like PHP typehints look like static typing but *aren't*, the same way
t
Hi!
> My proposal is simple: behave as an inline type hint. The same type hints
> you have in arguments lists, but inline. The use case is "I want to make
> sure this value is of this type" and a side benefit is the IDE can know the
> variable is of this type too (for autocompletion purposes).
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
51 matches
Mail list logo
