hi!
On Tue, Sep 3, 2013 at 12:17 AM, Stas Malyshev wrote:
> Hi!
>
At this point I would suggest to put the summary of the pros and cons
described (in a more or less exhaustive way) in the RFC and go for the
vote. Maybe double checks if there are any BC related issues that need
to be addressed as
On Sep 2, 2013, at 15:54, "Lester Caine" wrote:
> Parameter hashes are what we have been converting everything TO because it was
> supposed to be the 'proper way to do it' a few years back.
If you have lots of parameters to pass in, the better solution is to use an
object, which lets you formal
if I wanted strings or something else, that would be simple enough -
sprintf() will do the job.
in my case, I needed a scalar value that I can actually persist to the
database.
On Mon, Sep 2, 2013 at 4:21 PM, Stas Malyshev
wrote:
> Hi!
>
> > What I'm suggesting is simply a set of alternative f
Stas Malyshev wrote:
Option lists are everywhere, if you look at any framework everybody does
it. Of course, now they do it with option arrays, and if we accept that
option arrays are good then we don't need varargs either. But I thought
the idea was that option arrays are not good enough actuall
Hi!
> I think at some point you just need to go for "good enough" rather than
> "optimal support for everything". If we don't support the rather special
I am all for that. If only I wasn't this very minute bashed by several
other people for not accounting for every exotic use case and not
proposi
Hi!
> So what your saying, if I understand you correctly, is that PHP was
> intentionally designed to be non-deterministic? And it was designed that
> way to save a single character?
It is deterministic, there are rules for it, described in
http://us1.php.net/manual/en/language.namespaces.fallbac
On Tue, Sep 3, 2013 at 12:00 AM, Stas Malyshev wrote:
> Hi!
>
> > I already have a mostly-working implementation for named arguments and
> > unless I missed something critical it does not require us to redo
> > argument passing. The idea I followed was to keep the argument passing
> > pretty much
2013/9/2 Stas Malyshev
> Hi!
>
> > I would not agree with your argument that it should be introduced
> because it
> > is requested by real people for years and it is simple to add. Isn't that
> > pretty much the same as "because we can"?
>
> No, it is pretty much the opposite. It is "because peop
Hi!
> I already have a mostly-working implementation for named arguments and
> unless I missed something critical it does not require us to redo
> argument passing. The idea I followed was to keep the argument passing
> pretty much as-is, just instead of always pushing on top of the stack to
> pla
Stas,
On Mon, Sep 2, 2013 at 4:02 PM, Stas Malyshev wrote:
> Hi!
>
> > So the only case this effects is that you can't autoload a function from
> > the same namespace that you're currently in without explicitly using
> > that function.
> >
> > That's not such a huge issue.
>
> I think it is such
>>> I must say it seems a little strange for me given current stream of
>>> "because we can" syntax additions proposed to reject something that has
>>> been asked for by real people for years just because sometime in the
>>> future we might or might not have something that may do a similar thing
>>
On Mon, Sep 2, 2013 at 10:19 PM, Stas Malyshev wrote:
> Hi!
>
> > However I still wonder what prevents to finally implement named
> > parameters too, it will provide the same feature while being even more
>
> For named params, you need to rewrite all args handling, since now it is
> a positional a
Hi!
> I would not agree with your argument that it should be introduced because it
> is requested by real people for years and it is simple to add. Isn't that
> pretty much the same as "because we can"?
No, it is pretty much the opposite. It is "because people need it".
> IMO we should wait with
Hi Stanislav
I would not agree with your argument that it should be introduced because it
is requested by real people for years and it is simple to add. Isn't that
pretty much the same as "because we can"?
IMO we should wait with this RFC if Nikita is willing to write an RFC for
named parameters i
I don't like it. Empty is how it's done on any language which allows this
sort of thing, it's the most intuitive and I don't see anything wrong with
it.
If you need this, it probably means that your priorities are not set well
in the function. And if you have a function that has multiple optional
Oops, didn't mean to send a blank message, sorry all. Just clicked on the
wrong spot.
On Mon, Sep 2, 2013 at 2:11 PM, Stas Malyshev wrote:
> Hi!
>
> > I think this doesn't really help readability. Right now you should
> > implement functions with many options with an $options array.
>
> I don't understand. Who says I should do that? I certainly don't see how
> I should.
>
> > If we
Hi!
> What I'm suggesting is simply a set of alternative functions to
> ip2long() and crc32() that return consistent values on all platforms,
> e.g. 32-bit signed integer values - a couple of new functions and a
> couple of quick updates to the documentation explaining why you might
> want to use
Hi!
> However I still wonder what prevents to finally implement named
> parameters too, it will provide the same feature while being even more
For named params, you need to rewrite all args handling, since now it is
a positional array and that doesn't work with named args. On the way
you'd have t
Hi!
> What would happen if I had done:
>
> define('default', 42);
>
> before that line?
Pretty much the same as if you did:
define('if', 42);
if($a == 1) print "one";
default is a keyword.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext.
Hi!
> The function names might look like this:
> - spl_register_autoloader -> autoloader for everything
Given we already have spl_autoload_register that'd be pretty confusing.
Also, we usually name functions in increasing order of specificity (i.e.
spl_autoload_call/spl_autoload_spl_autoload_func
Hi!
> I think this doesn't really help readability. Right now you should
> implement functions with many options with an $options array.
I don't understand. Who says I should do that? I certainly don't see how
I should.
> If we want to change something here, we should skip this step and go
> rig
Hi!
> another small advantage would be that IDEs could show you the default
> value for the argument when hovering the default keyword.
That actually would be excellent if they did it. I hope (if this is
accepted) everybody does.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sug
Hi!
> So the only case this effects is that you can't autoload a function from
> the same namespace that you're currently in without explicitly using
> that function.
>
> That's not such a huge issue.
I think it is such a huge issue, because this means this functionality
can not be used for rel
>
> > interface foo {
> > function formatUseCases(...$options); }
> > - Advantage: No dependency on a class / object
> > - Disadvantage: doesn't document what options are available, no
> > default parameters
> >
>
>
> This is totally not a use case for variadic functions. The arguments of a
>
2013/9/2 jbo...@openmv.com
> On Mon Sep 2 08:52 AM, Sebastian Krebs wrote:
> > 2013/9/2 Pierre Joye
> >
> > > >
> > > > Any comments or feedback on the RFCs and the code are welcome,
> > > > especially pointing out the cases where it may not work (which means
> > > > we need more phpt's there :)
No, just this thread of e-mails.
What I'm suggesting is simply a set of alternative functions to ip2long()
and crc32() that return consistent values on all platforms, e.g. 32-bit
signed integer values - a couple of new functions and a couple of quick
updates to the documentation explaining why you
On Mon Sep 2 08:52 AM, Sebastian Krebs wrote:
> 2013/9/2 Pierre Joye
>
> > >
> > > Any comments or feedback on the RFCs and the code are welcome,
> > > especially pointing out the cases where it may not work (which means
> > > we need more phpt's there :)
> >
> > Using default instead of ,,, is i
On Mon, Sep 2, 2013 at 12:37 AM, Pierre Joye wrote:
> On Mon, Sep 2, 2013 at 12:08 AM, Stas Malyshev wrote:
>
>> So I'd go for fixing what is broken and not fixing what isn't :)
>
> Right, I am on it. Snaps page works now except for master. I will
> finish that this week.
>
> As of the announceme
Nicolas,
namespace foo {
>> something(); // autoloaded as "something"
>> }
>>
>
> That makes sense *for me* for many reasons, but IMHO that's too confusing
> for a wider adoption.
> Because this doesn't work for function foo\strlen, the only reasonable way
> to work with such an autoloader wo
Stas,
> namespace foo {
> > use function biz\buz;
> > use foo\bar;
> >
> > something(); // autoloaded as "something"
>
> Wait, so it wouldn't work like class autoloader, using fully qualified
> name? And autoloader would not then have any information about
> namespaces, so you'd have t
2013/9/2 Pierre Joye
> hi Stas,
>
> On Mon, Sep 2, 2013 at 9:17 AM, Stas Malyshev
> wrote:
> > Hi!
> >
> > I've finally took some time to revive the skipping parameter RFC and
> > patch. For those who doesn't remember what it is please see:
> > https://wiki.php.net/rfc/skipparams
> > TLDR versio
>
> namespace foo {
> something(); // autoloaded as "something"
> }
>
That makes sense *for me* for many reasons, but IMHO that's too confusing
for a wider adoption.
Because this doesn't work for function foo\strlen, the only reasonable way
to work with such an autoloader would be to avoid us
hi Stas,
On Mon, Sep 2, 2013 at 9:17 AM, Stas Malyshev wrote:
> Hi!
>
> I've finally took some time to revive the skipping parameter RFC and
> patch. For those who doesn't remember what it is please see:
> https://wiki.php.net/rfc/skipparams
> TLDR version:
>
> The idea is to allow skipping param
On Mon, Sep 2, 2013 at 12:48 PM, Derick Rethans wrote:
> On Mon, 2 Sep 2013, Stas Malyshev wrote:
>
> > Hi!
> >
> > I've finally took some time to revive the skipping parameter RFC and
> > patch. For those who doesn't remember what it is please see:
> > https://wiki.php.net/rfc/skipparams
> > TLD
On Mon, Sep 2, 2013 at 11:47 AM, Derick Rethans wrote:
> On Wed, 28 Aug 2013, Nikita Popov wrote:
>
> > On Thu, May 23, 2013 at 8:40 PM, Daniel Lowrey
> wrote:
> >
> > > I'm probably not the typical PHP user; I spend 99% of my PHP time
> > > using the CLI (and not web SAPIs).
> > > This means th
On Mon, 2013-09-02 at 11:48 +0100, Derick Rethans wrote:
> > can be called like this:
> > create_query("deleted=0", "name", default, default, /*report_errors*/
> > true);
>
> What would happen if I had done:
>
> define('default', 42);
>
> before that line?
Nothing special as default
2013/9/2 Lester Caine
> Ferenc Kovacs wrote:
>
>>
>> you write your code where you copypaste the default value
>> some time passes
>> somebody changes the default value in the called function definition
>> your code now calls the function with a non-default value.
>>
>
> Actually THAT is a proble
On Mon, 2 Sep 2013, Stas Malyshev wrote:
> Hi!
>
> I've finally took some time to revive the skipping parameter RFC and
> patch. For those who doesn't remember what it is please see:
> https://wiki.php.net/rfc/skipparams
> TLDR version:
>
> The idea is to allow skipping parameters in function wi
Ferenc Kovacs wrote:
you write your code where you copypaste the default value
some time passes
somebody changes the default value in the called function definition
your code now calls the function with a non-default value.
Actually THAT is a problem I've hit in reverse! Some bugger changing t
On Mon, Sep 2, 2013 at 12:24 PM, Lester Caine wrote:
> Jannik Zschiesche wrote:
>
>> another small advantage would be that IDEs could show you the default
value
for the argument when hovering the default keyword.
>>> But a good IDE is already showing the full function and notes ...
Jannik Zschiesche wrote:
another small advantage would be that IDEs could show you the default value
for the argument when hovering the default keyword.
But a good IDE is already showing the full function and notes ... and will
autocomplete so that this fix is not actually required :)
In many c
On Wed, 28 Aug 2013, Nikita Popov wrote:
> On Thu, May 23, 2013 at 8:40 PM, Daniel Lowrey wrote:
>
> > I'm probably not the typical PHP user; I spend 99% of my PHP time
> > using the CLI (and not web SAPIs).
> > This means that I frequently run PHP without an .ini file. As a
> > result, when I u
On Mon, Sep 2, 2013 at 9:17 AM, Stas Malyshev wrote:
> Hi!
>
> I've finally took some time to revive the skipping parameter RFC and
> patch. For those who doesn't remember what it is please see:
> https://wiki.php.net/rfc/skipparams
> TLDR version:
>
> The idea is to allow skipping parameters in f
Am Montag, 2. September 2013 um 11:02 schrieb Lester Caine:
> Ferenc Kovacs wrote:
> > another small advantage would be that IDEs could show you the default value
> > for the argument when hovering the default keyword.
> >
>
> But a good IDE is already showing the full function and notes ...
Ferenc Kovacs wrote:
another small advantage would be that IDEs could show you the default value
for the argument when hovering the default keyword.
But a good IDE is already showing the full function and notes ... and will
autocomplete so that this fix is not actually required :)
In many case
It is approaching 2 1/2 years since the last release of PHP 5.2. 5.2
has been declared dead on more than one occasion around here. The dust
has more or less settled since PHP 5.3 EOL was announced. The ONLY
reason I still support 5.2 in my own userland software is because the
5.2 binaries ar
On Mon, Sep 2, 2013 at 9:41 AM, Stas Malyshev wrote:
> Hi!
>
> > I am not sure whether this is a little overhead.
> >
> > but if we do want this. to be honest, I even prefer leave it empty to
> > "default".
> >
> > like create_query("delete=0", "name", , , true);
>
> That's how it was initially
On Mon, Sep 2, 2013 at 9:41 AM, Stas Malyshev wrote:
> Hi!
>
>> I am not sure whether this is a little overhead.
>>
>> but if we do want this. to be honest, I even prefer leave it empty to
>> "default".
>>
>> like create_query("delete=0", "name", , , true);
>
> That's how it was initially, and
Hi!
> Yes, all of these problems can be solved - I am well aware of that. I am
> also painfully aware of how much time it can take to solve them reliably.
>
> I just would like to see a solution rather than a bunch of work-arounds -
> not for my own sake, my problem is solved, but for the sake of
Hi!
> Stas, does this problem still persist for you?
Yes, the test is still failing for me, and also seems to fail on Travis
periodically, see: https://travis-ci.org/php/php-src/builds/10751907
The output I'm getting is this:
Test
PHP 5.6.0-dev Development Server started at Mon Sep 2 07:49:11
Hi!
> I am not sure whether this is a little overhead.
>
> but if we do want this. to be honest, I even prefer leave it empty to
> "default".
>
> like create_query("delete=0", "name", , , true);
That's how it was initially, and I was convinced default is better. So I
don't think I'm going ba
Hi!
> namespace foo {
> use function biz\buz;
> use foo\bar;
>
> something(); // autoloaded as "something"
Wait, so it wouldn't work like class autoloader, using fully qualified
name? And autoloader would not then have any information about
namespaces, so you'd have to specify explic
On Mon, Sep 2, 2013 at 3:17 PM, Stas Malyshev wrote:
> Hi!
>
> I've finally took some time to revive the skipping parameter RFC and
> patch. For those who doesn't remember what it is please see:
> https://wiki.php.net/rfc/skipparams
> TLDR version:
>
> The idea is to allow skipping parameters in f
Hi!
I've finally took some time to revive the skipping parameter RFC and
patch. For those who doesn't remember what it is please see:
https://wiki.php.net/rfc/skipparams
TLDR version:
The idea is to allow skipping parameters in function with optional
arguments so that this:
function create_que
55 matches
Mail list logo
