On Sep 7, 2013 4:37 AM, "Yasuo Ohgaki" wrote:
>
> Hi,
>
> Any updates for "Escaping RFC for PHP Core"?
> https://wiki.php.net/rfc/escaper
>
> I think this is must have item for next PHP.
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
Looks like the rfc author was unable to implement it himself at th
Matthew Leverton wrote:
On Fri, Sep 6, 2013 at 8:56 PM, Ryan McCue wrote:
Matthew Leverton wrote:
This is already the case. In libraries that accept options via an array,
those array keys are pretty much set in stone (although you can map them
if you need to change a key).
The big difference
Hi,
Any updates for "Escaping RFC for PHP Core"?
https://wiki.php.net/rfc/escaper
I think this is must have item for next PHP.
--
Yasuo Ohgaki
yohg...@ohgaki.net
On Fri, Sep 6, 2013 at 8:56 PM, Ryan McCue wrote:
> Matthew Leverton wrote:
> This is already the case. In libraries that accept options via an array,
> those array keys are pretty much set in stone (although you can map them
> if you need to change a key).
>
The big difference here is if I accept
Matthew Leverton wrote:
> What I don't like about named parameters is that if I build a library,
> now even my parameter names are unchangeable if I don't want to break
> any backward compatibility, since I never know if somebody will decide
> to call my single parameter method with named parameter
Still funny, but that troll has been played before. I don't think anyone's
suggested the Euro yet though, maybe go for that next time.
On Fri, Sep 6, 2013 at 2:48 PM, yigal irani wrote:
> make all dollar sign usage optional except in double quoted strings and
> when calling calling functions b
make all dollar sign usage optional except in double quoted strings and
when calling calling functions by variable.
relevant:
http://www.reddit.com/r/PHP/comments/1ltulg/what_single_feature_do_you_want_to_see_added_to/cc2t7eu
On Fri, Sep 6, 2013 at 11:23 PM, Gustavo Lopes wrote:
> I like the idea, but I think you're approaching this the wrong way. In my
> opinion, you should emulate the current behavior as close as possible. For
> instance:
>
> func_get_args() will not include the missing offsets in the resulting
>> a
On Sat, Sep 7, 2013 at 12:18 AM, Sara Golemon wrote:
> Still funny, but that troll has been played before. I don't think anyone's
> suggested the Euro yet though, maybe go for that next time.
>
>
> On Fri, Sep 6, 2013 at 2:48 PM, yigal irani wrote:
>
> > make all dollar sign usage optional exce
How about.. no.
http://d24w6bsrhbeh9d.cloudfront.net/photo/aKzPQgW_460sa.gif
On Sat, Sep 7, 2013 at 1:18 AM, Sara Golemon wrote:
> Still funny, but that troll has been played before. I don't think anyone's
> suggested the Euro yet though, maybe go for that next time.
>
>
> On Fri, Se
+1 to named params. Please please please. :)
=> is my vote for syntax. Makes sense. Doesn't make sense to introduce another
way to express something we've been used to for years with key => value, and is
it that important to save one character per assignment?
On Sep 6, 2013, at 9:39 AM, Nikita
On 06-09-2013 18:39, Nikita Popov wrote:
I created an RFC and preliminary implementation for named parameters:
https://wiki.php.net/rfc/named_params
The RFC and implementation are not yet complete. I mainly want to have
feedback on the idea in general and on the Open Questions (
https://w
Hi Adam
> I'd say the odds are that those sorts of users are going to be writing
> code that is required to be notice/strict clean anyway — that's
> certainly been true everywhere I've worked that's had a "modern"
> codebase.
Yes, so say you have a team that:
* currently has a code base that is
George Bond wrote:
> Then the double-dollar syntax would seem the obvious choice to me:
> foo( $$param => 'whatever' );
> Which is no less readable than anywhere else the double-dollar is
> allowed... :-p
For the simple case I agree having double $$ signs is not that bad, but it
would get nasty
On 6 September 2013 13:01, Dan Ackroyd wrote:
>> I'd say the odds are that those sorts of users are going to be writing
>
>> code that is required to be notice/strict clean anyway — that's
>> certainly been true everywhere I've worked that's had a "modern"
>> codebase.
>
> Yes, so say you have a t
On Fri, Sep 6, 2013 at 11:39 AM, Nikita Popov wrote:
> The RFC and implementation are not yet complete. I mainly want to have
> feedback on the idea in general and on the Open Questions (
> https://wiki.php.net/rfc/named_params#open_questions) in particular.
>
I feel like this will just encourage
On 6 September 2013 12:12, Dan Ackroyd wrote:
>> If named parameters are introduced, signature validation should include
>> parameter names. Throwing a fatal error (for the interface/class
> combination)
>> would break backwards compatibility though. We could use some lower error
>> type...
>
> Wo
Hi Nikita,
> If named parameters are introduced, signature validation should include
> parameter names. Throwing a fatal error (for the interface/class
combination)
> would break backwards compatibility though. We could use some lower error
> type...
Would it be possible to set the error level th
Regarding variable parameter names; if the syntax was:
function foo( $firstParameter ) { ... }
foo( $firstParameter=> 'foo' );
Then the double-dollar syntax would seem the obvious choice to me:
function foo( $firstParameter ) { ... }
$param = 'firstParameter';
foo( $$param => 'whatever' );
Whic
2013/9/6 Adam Harvey
>
>
> Variadics/splat: collecting both named and positional arguments into
> one array seems reasonable to me. I think the main use case there
> would be option parameters, which you'd have to validate anyway, so
> positional parameters would be dealt with at that point — I do
Le 06/09/2013 18:39, Nikita Popov a écrit :
Hi internals!
I created an RFC and preliminary implementation for named parameters:
https://wiki.php.net/rfc/named_params
The RFC and implementation are not yet complete. I mainly want to have
feedback on the idea in general and on the Open Ques
Hi,
On Fri, 2013-09-06 at 18:39 +0200, Nikita Popov wrote:
> Hi internals!
>
> I created an RFC and preliminary implementation for named parameters:
>
> https://wiki.php.net/rfc/named_params
>
> The RFC and implementation are not yet complete. I mainly want to have
> feedback on the idea in
On Fri, Sep 6, 2013 at 6:01 PM, Pascal Chevrel wrote:
> Le 06/09/2013 18:39, Nikita Popov a écrit :
>
>> Hi internals!
>>
>> I created an RFC and preliminary implementation for named parameters:
>>
>> https://wiki.php.net/rfc/named_params
>>
>> The RFC and implementation are not yet complete.
Hi Nikita,
Will it be possible to set the named parameter through using a parameter?
i.e. can you do:
function multipleParamFunction($var1 = null, $var2 = null, $var3 = null,
$var4 = null) {
//...
}
$paramToOverride = 'var3';
testFunction($paramToOverride => 'bar');
which would override 'var3'
I like!
My preference on syntax is;
test(:foo => "oof", :bar => "rab");
I don't think;
test("foo" => "oof", "bar" => "rab");
denotes enough emphasis on any part in-particular, and the downsides
of other implementations are mentioned, such as variable names and
collisions with reserved keywords
Dan,
That's a good question as well, with the current $var syntax I'm assuming NO.
You're using the $var3 name as a key, not as the $paramToOverride value.
Maybe the collon could be used here?
$paramToOverride = 'var3';
testFunction(:$paramToOverride => 'bar'); // Colon before $ would make
the k
On 6 September 2013 09:39, Nikita Popov wrote:
> The RFC and implementation are not yet complete. I mainly want to have
> feedback on the idea in general and on the Open Questions (
> https://wiki.php.net/rfc/named_params#open_questions) in particular.
Thanks for proposing this. I haven't looked
Hi internals!
I created an RFC and preliminary implementation for named parameters:
https://wiki.php.net/rfc/named_params
The RFC and implementation are not yet complete. I mainly want to have
feedback on the idea in general and on the Open Questions (
https://wiki.php.net/rfc/named_params#o
> if I were to suggest that they be enabled by default would everyone recoil
> in horror?
I'd certainly be up for this as it would make my life easier and eliminate
the need for changes to the streams API. Environments like shared hosting
could easily pass a --disable-sockets configure option or s
> So what's the ultimate goal? Do we want to do try to move away from the
> sockets extension? Or should we maintain the status quo (broad support for
> standard use-cases with the extension there if you need more)?
After consideration, I think I tend towards the latter - bringing the more
complex
Hi, all -
Not sure why the domain @metrodigi.com is on this working group's list. I
did not sign up for it.
Since I have to "put up" with the email noise, I might as well get
something out of it so here goes:
We are a well funded, rapidly growing tech company working near San
Francisco that is l
This is a reasonable point. Personally I'd prefer to have as much socket
functionality as possible available natively without an extension. More
discussion is probably necessary on this point, though.
So what's the ultimate goal? Do we want to do try to move away from the
sockets extension? Or sho
I'm generally agreed with everything said below by everyone - but Wez's
message has
caused me to wonder whether it might be worth simply creating
stream_import_socket()
instead.
Yes, the sockets extension is not always available, but I would suggest that
any
instance that needs something that stre
33 matches
Mail list logo
