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
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
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
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
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
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 (
On 6 September 2013 09:39, Nikita Popov nikita@gmail.com 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.
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
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.
Thanks,
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'
On Fri, Sep 6, 2013 at 6:01 PM, Pascal Chevrel pascal.chev...@free.fr 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
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
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
2013/9/6 Adam Harvey ahar...@php.net
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
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' );
Which
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
On 6 September 2013 12:12, Dan Ackroyd dan...@basereality.com 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
On Fri, Sep 6, 2013 at 11:39 AM, Nikita Popov nikita@gmail.com 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
On 6 September 2013 13:01, Dan Ackroyd dan...@basereality.com 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
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 for
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
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 (
+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
How about.. no.
http://d24w6bsrhbeh9d.cloudfront.net/photo/aKzPQgW_460sa.gif
On Sat, Sep 7, 2013 at 1:18 AM, Sara Golemon poll...@php.net 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 Sat, Sep 7, 2013 at 12:18 AM, Sara Golemon poll...@php.net 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 yi...@symbolclick.com wrote:
make all
On Fri, Sep 6, 2013 at 11:23 PM, Gustavo Lopes glo...@nebm.ist.utl.ptwrote:
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
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
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 yi...@symbolclick.com wrote:
make all dollar sign usage optional except in double quoted strings and
when calling
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 parameters.
On Fri, Sep 6, 2013 at 8:56 PM, Ryan McCue li...@rotorised.com 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
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
Matthew Leverton wrote:
On Fri, Sep 6, 2013 at 8:56 PM, Ryan McCue li...@rotorised.com 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).
On Sep 7, 2013 4:37 AM, Yasuo Ohgaki yohg...@ohgaki.net 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
33 matches
Mail list logo
