> On Jan 14, 2021, at 12:56, Andrew Brown wrote:
>
> I know named arguments are a hotly contested feature right now, and
> honestly I'm not sure where I fall on them right now. But I would also see
> this as a complement to named parameters.
>
> I can see this feature has been debated heavily i
Thanks for the feedback. Thanks for the tip on avoiding embedded images.
*Anna*: Definitely agree that long signatures, along with lots of optional
parameters can be signs of other issues.
That's why I used a 3 parameter signature in my example, where it's
"required", "optional", "optional", whic
Hi,
It looks like your images have broken (Random guess: the list may remove
attachments).
As a general rule, I would suggest avoiding screenshots for code. Common
mailing list etiquette for development lists is to avoid attachments or
embedded remote images as these tend to get lost in hist
This is handled in a more elegant way by the named arguments of PHP8
https://stitcher.io/blog/php-8-named-arguments With that feature you can
just pass the parameters that you need and the others will get their
default values
Barel
On Thu, 14 Jan 2021 at 18:12, Anna Filina wrote:
> > So if some
> So if some calling code wants to override a later parameter, it currently
needs to pass a value to the earlier optional parameters.
I think that this is a code smell that should be addressed by a better
design. Here's a detailed explanation of why one should use default
parameters sparingly, alo
This is my first foray into PHP internals, so please let me know if I'm
doing something wrong. Currently just following the instructions from
https://wiki.php.net/rfc/howto.
Currently this proposal is only a "concept".
I propose we add a "default" keyword that can be passed as an argument into
a
Hi Nikita,
2013/7/19 Nikita Popov
> I don't think we should add string decrementing due to the rather complex
> logic behind it (imho the string incrementing that we have shouldn't be
> there either).
>
Right. It is impossible to symmetric operation ++/-- for strings.
Not implementing --'STRING
What's the intended use case for string increment / decrement?
>>> Personally, I instantly think of mirroring spreadsheet columns - works
>>> quite well in that context.
>>>
>>
>> ++/-- 'XYZ1234' would have use cases.
I once had an app which needed to generate long continuous ra
On 19 July 2013 12:34, Yasuo Ohgaki wrote:
> Hi,
>
> 2013/7/19 Peter Lind
>
>> On 19 July 2013 11:18, Dan Cryer wrote:
>>
>>> What's the intended use case for string increment / decrement?
>>>
>>>
>> Personally, I instantly think of mirroring spreadsheet columns - works
>> quite well in that co
On Thu, Jul 18, 2013 at 3:46 PM, Chris London wrote:
> My friend shared some code with me today that wasn't working for him. He
> was incrementing letters like this:
>
> $letter = 'A';
> echo ++$letter; // Output: B
>
> He was then trying to decrement letters like this:
>
> $letter = 'B';
> echo
Hi,
2013/7/19 Peter Lind
> On 19 July 2013 11:18, Dan Cryer wrote:
>
>> What's the intended use case for string increment / decrement?
>>
>>
> Personally, I instantly think of mirroring spreadsheet columns - works
> quite well in that context.
>
++/-- 'XYZ1234' would have use cases.
>
>
On 19 July 2013 11:18, Dan Cryer wrote:
> What's the intended use case for string increment / decrement?
>
>
Personally, I instantly think of mirroring spreadsheet columns - works
quite well in that context.
> It just seems like madness to me, using mathematical operators with
> strings, produc
On Fri, Jul 19, 2013 at 5:18 PM, Dan Cryer wrote:
> What's the intended use case for string increment / decrement?
>
+ 1
could we please stop wasting time on such issues? many thanks
> It just seems like madness to me, using mathematical operators with
> strings, producing seemingly arbitrary
What's the intended use case for string increment / decrement?
It just seems like madness to me, using mathematical operators with
strings, producing seemingly arbitrary results in some circumstances (C ->
B -> A -> NULL / False ?).
Also what happens in other languages? Take for example German, i
Hi,
I take a look at the code.
It does support [0-9] also.
[yohgaki@dev tests]$ php -r "\$a = ' a10';for (\$i=0; \$i<10;\$i++)
var_dump(++\$a);"
string(4) " a11"
string(4) " a12"
string(4) " a13"
string(4) " a14"
string(4) " a15"
string(4) " a16"
string(4) " a17"
string(4) " a18"
string(4) " a19"
Interesting to note that although Perl 6 is apparently capable of
decrementing strings, it doesn't fully mirror the incrementing:
http://feather.perl6.nl/syn/S03.html#line_516
Specifically: decrementing 'AAA' would not turn into 'ZZ' but would error,
according to that link
--
WWW: plphp.dk / p
Hi,
2013/7/19 Mateusz Kocielski
> > see http://www.php.net/manual/en/language.operators.increment.php
>
> I don't see any explanation for the examples above. Documentation says:
>
> [...] For example, in PHP and Perl $a = 'Z'; $a++; turns $a into 'AA' [...]
>
> I'd expect " ZZ" to become " AAA"
On Thu, Jul 18, 2013 at 4:37 PM, Xinchen Hui wrote:
>> Hello,
>>
>> Does anybody understand the rules behind the string incrementation? What's
>> the explanation of following behaviour?
>>
>> '$x="ZZ";$x++;var_dump($x);' returns string(3) "AAA"
>> '$x=" ZZ";$x++;var_dump($x);' returns string(3) "
On Thu, Jul 18, 2013 at 7:18 PM, Chris London wrote:
> I hear Perl 6 supports Str decrementing
>
>
I heard of Perl 6 once.
I hear Perl 6 supports Str decrementing
On Jul 18, 2013 5:11 PM, "Sara Golemon" wrote:
> > My question is, why specifically doesn't it?
> >
> > Because Perl.
>
> My question is, why specifically doesn't it?
>
> Because Perl.
The one caveat about decrementing "A" and it goes to NULL is that if you
increment NULL it goes to 1 so that may be confusing. We could also
decrement "A" and it goes to FALSE and FALSE++ is still FALSE
On Thu, Jul 18, 2013 at 1:10 PM, Phil Sturgeon wrote:
> Incrementing "Z" results in "AA", b
Something I learned today is incrementing 'Z' goes to 'AA' but that helps
the point that it could use more work/clarification
On Thu, Jul 18, 2013 at 1:08 PM, Martin Amps wrote:
> One hiccup. I imagine maybe the reason we don't support decrementing is
> because what would happen if you tried to
> One hiccup. I imagine maybe the reason we don't support decrementing is
> because what would happen if you tried to decrement 'A'. In that case I
> would suggest either returning NULL or throwing a notice.
It would make sense to make it stay as ‘A’ like incrementing ‘Z' stays as ‘Z’.
I do agree
在 2013-7-18，22:31，Mateusz Kocielski 写道：
It seems logical that if we support increment we should support decrement.
My proposal:
1) Support decrementing letters
- or -
2) Throw a notice explaining that decrementing is not supported so
developers quickly know they can't do that
One hiccup.
On Thu, 2013-07-18 at 07:46 -0600, Chris London wrote:
> My friend shared some code with me today that wasn't working for him. He
> was incrementing letters like this:
>
> $letter = 'A';
> echo ++$letter; // Output: B
>
> He was then trying to decrement letters like this:
>
> $letter = 'B';
> ec
> It seems logical that if we support increment we should support decrement.
>
> My proposal:
>
> 1) Support decrementing letters
> - or -
> 2) Throw a notice explaining that decrementing is not supported so
> developers quickly know they can't do that
>
> One hiccup. I imagine maybe the reason we
My friend shared some code with me today that wasn't working for him. He
was incrementing letters like this:
$letter = 'A';
echo ++$letter; // Output: B
He was then trying to decrement letters like this:
$letter = 'B';
echo --$letter; // Output: B
He was really confused why his code wasn't work
Hi,
well, my apologies for not making that clear enough. I suppose it
wouldn't require any runtime information, as this kind of construct
could be expanded at compile time.
For example:
willUse('LibraryWithAVeryLongName\Cache\FileCache')
->willUse('LibraryWithAVeryLongName\Routing\Cach
Hi!
unqualified aliases, it would be useful to extend this functionality
to string references to these classes/functions/constants as well.
It would require to carry "namespace context" around with every
function/class in runtime and for me the usecase is not clear. Can you
describe more in
On Sat, Jul 31, 2010 at 2:14 PM, Ignas Rudaitis
wrote:
> Hello php.internals,
>
> Here is a (hopefully) simple language feature I'd like to suggest:
>
> Now that PHP has support for namespaces and therefore makes it
> possible to refer to classes, functions and constants by their shorter
> unquali
Hello php.internals,
Here is a (hopefully) simple language feature I'd like to suggest:
Now that PHP has support for namespaces and therefore makes it
possible to refer to classes, functions and constants by their shorter
unqualified aliases, it would be useful to extend this functionality
to str
Hi Eric,
I don't see very much value in such an option and I doubt it would help
run-tme very much. In any case, the access control is very much part of the
infrastructure and it can't just be skipped very easily.
Andi
At 11:32 AM 4/16/2004 +0200, Eric Daspet wrote:
Hi,
Is it possible or plan
Hi,
Is it possible or planned to have a php.ini option in order to disable
interfaces and access control ? something like assert.active for assertions.
What I mean is something like a option "access_control.active". If it is
disabled then PHP do not check private/public/protected access, do not
Sorry, but didn't all there error/warnings/info got logged if you want ? I
think you can set loggin on in php.ini and IMHO that's the best place to dig
for bugs...
Cristiano Duarte.
"Wojtek Meler" <[EMAIL PROTECTED]> escreveu na mensagem
news:[EMAIL PROTECTED]
> Timm Friebe wrote:
> > On Tue, 200
Timm Friebe wrote:
On Tue, 2003-07-22 at 19:48, Wojtek Meler wrote:
I have to fight with people that using error suppression operator - they
just hide their bugs.
I wrote simple patch that allows set disable_error_suppression=On in
php.ini that causes engine to ignore '@' operators.
Use set_er
On Tue, 2003-07-22 at 19:48, Wojtek Meler wrote:
> I have to fight with people that using error suppression operator - they
> just hide their bugs.
> I wrote simple patch that allows set disable_error_suppression=On in
> php.ini that causes engine to ignore '@' operators.
Use set_error_handler()
Mike Robinson topquoted:
> No offense, but I see this feature as a bad thing in so many ways
> and on so many levels my skin is crawling. :)
>
>
> Regards
>
> Mike Robinson
> http://fiddy8.com/
>
>
> > I have to fight with people that using error suppression
> operator - they
> > just hide t
Ken Tossell wrote:
But often errors/warnings are *not* bugs. Or maybe you don't want to
show your users the ugly messages from something like include -- if
([EMAIL PROTECTED] 'foo.php') die('Couldn\'t..');
Well it is true. Sometimes it is needed and that's why this
functionality is turned of
I have to fight with people that using error suppression operator - they
just hide their bugs.
I wrote simple patch that allows set disable_error_suppression=On in
php.ini that causes engine to ignore '@' operators.
But often errors/warnings are *not* bugs. Or maybe you don't want to
show
No offense, but I see this feature as a bad thing in so many ways
and on so many levels my skin is crawling. :)
Regards
Mike Robinson
http://fiddy8.com/
> I have to fight with people that using error suppression operator - they
> just hide their bugs.
> I wrote simple patch that allows set di
I have to fight with people that using error suppression operator - they
just hide their bugs.
I wrote simple patch that allows set disable_error_suppression=On in
php.ini that causes engine to ignore '@' operators.
http://strony.wp.pl/wp/wmeler/error_suppression.patch.txt
Regards,
Wojtek
--
PH
42 matches
Mail list logo
