Hi!
> class Baz extends Bar {
> function foo($a=default, $b=default) {
> // do something
> parent::foo($a, $b);
> }
> }
I tried to implement this, however there's a major issue that I do not
know how to overcome. The issue is that when we compile method foo() we
do not kno
On 20 January 2015 at 20:09, Marc Bennewitz wrote:
> Pros & Cons
>
> _Named Parameters:_
> pro:
> - readability (If caller is not required to call as assoc array)
> - not an option for inheritance
> con:
> - paramter skipping is a side product with possible edge cases
> - Adds var
On 20/01/2015 20:09, Marc Bennewitz wrote:
Am 19.01.2015 um 19:48 schrieb Adam Harvey:
On 17 January 2015 at 18:04, Andrea Faulds wrote:
For consistency with list(), we could also just put nothing:
foo($bar, , $baz);
Which is like:
list($bar, , $baz) = $arr;
Thoughts?
That was
Hi!
> @Stas: Any news on using default on inheritance ?
Not yet, probably will look into this towards next weekend.
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Am 19.01.2015 um 19:48 schrieb Adam Harvey:
On 17 January 2015 at 18:04, Andrea Faulds wrote:
For consistency with list(), we could also just put nothing:
foo($bar, , $baz);
Which is like:
list($bar, , $baz) = $arr;
Thoughts?
That was Stas's original, original proposal way back
On 17 January 2015 at 18:04, Andrea Faulds wrote:
> For consistency with list(), we could also just put nothing:
>
>
> foo($bar, , $baz);
>
> Which is like:
>
> list($bar, , $baz) = $arr;
>
> Thoughts?
That was Stas's original, original proposal way back when. I argued
then for having "de
Rasmus,
> _ is not really an option since it is the standard gettext() shortcut.
Yup, Simon J. pointed that out too so usage of `_` was already a discarded
topic.
The top topic now is a possible consistency with the syntax already allowed
when using list. Ex:
list($bar, , $baz) = ['good', 'trash
On Jan 17, 2015, at 17:52, Marcio Almada wrote:
>> Cryptic notation is not a PHP way. IMHO.I like original "default" proposal
>> and it is good enough.
>> Regards,
>
> When I suggested `_` it was more as a feature wandering. I like
> `default` too. The RFC looks good enough as it is now :)
_ i
Hey Marcio,
> On 18 Jan 2015, at 02:22, Marcio Almada wrote:
>
> Andrea,
>
>> For consistency with list(), we could also just put nothing:
>>
>> foo($bar, , $baz);
>>
>> Which is like:
>>
>> list($bar, , $baz) = $arr;
>>
>> Thoughts?
>
> Not sure. Do we consider both contexts (list assi
Andrea,
> For consistency with list(), we could also just put nothing:
>
>foo($bar, , $baz);
>
> Which is like:
>
> list($bar, , $baz) = $arr;
>
> Thoughts?
Not sure. Do we consider both contexts (list assignment skipping and
parameter skipping) as assignments? If so, then the consistency
a
Hi Marcio,
> On 18 Jan 2015, at 02:01, Marcio Almada wrote:
>
> Just a note:
>
> I still think a single char token (like `~`) would look great and
> wouldn't be "cryptic" like Yasuo argued. But, as said before, it's
> just a minor observation. The `default` token is a great option and
> sounds
Just a note:
I still think a single char token (like `~`) would look great and
wouldn't be "cryptic" like Yasuo argued. But, as said before, it's
just a minor observation. The `default` token is a great option and
sounds very intuitive to anyone I've asked for opinions.
2015-01-17 22:52 GMT-03:00
> Cryptic notation is not a PHP way. IMHO.I like original "default" proposal
> and it is good enough.
> Regards,
When I suggested `_` it was more as a feature wandering. I like
`default` too. The RFC looks good enough as it is now :)
2015-01-17 22:14 GMT-03:00 Yasuo Ohgaki :
> Hi all,
>
> On Fri
Hi all,
On Fri, Jan 16, 2015 at 7:29 PM, Patrick Schaaf wrote:
> Am 14.01.2015 20:50 schrieb "Simon J Welsh" :
> >
> > >create_query("deleted=0", "name", _, _, true);
> > >
> > > Still not sure if it's better than `default`, though.
> >
> > That would be a BC break as you can currently have
> -Ursprüngliche Nachricht-
> Von: Stanislav Malyshev [mailto:smalys...@gmail.com]
> Gesendet: Freitag, 16. Januar 2015 21:35
> An: Robert Stoll; 'Marc Bennewitz'; internals@lists.php.net
> Betreff: Re: AW: [PHP-DEV] [RFC] Skipping parameters take 2
>
> H
Hi!
> This would be quite a nice feature, even if this RFC does not pass.
> Just as hint, there are ambiguous case which need to be considered:
>
> interface A{ function foo($a=1); } interface B{ function
> foo($a="hi"); } class C implements A, B{ function foo($a=default){}
> //what would be the
Hi Robert
Am 16.01.2015 um 11:04 schrieb Robert Stoll:
Hi Stas,
-Ursprüngliche Nachricht-
Von: Stanislav Malyshev [mailto:smalys...@gmail.com]
Gesendet: Mittwoch, 14. Januar 2015 21:26
An: Marc Bennewitz; internals@lists.php.net
Betreff: Re: [PHP-DEV] [RFC] Skipping parameters take 2
Am 14.01.2015 20:50 schrieb "Simon J Welsh" :
>
> >create_query("deleted=0", "name", _, _, true);
> >
> > Still not sure if it's better than `default`, though.
>
> That would be a BC break as you can currently have a constant _.
A visually pleasing (IMO), even easier to type, and non-BC altern
Hi Stas,
> -Ursprüngliche Nachricht-
> Von: Stanislav Malyshev [mailto:smalys...@gmail.com]
> Gesendet: Mittwoch, 14. Januar 2015 21:26
> An: Marc Bennewitz; internals@lists.php.net
> Betreff: Re: [PHP-DEV] [RFC] Skipping parameters take 2
>
> Hi!
>
> > Is
Hi!
> It's not part of the original proposal, and I'm not sure how easy it
> would be to implement, but it sounds like a nice extension, I didn't
> think about it. Since the RFC is already in vote, I won't change it now,
Strike that, I was confused, for some reason I thought I've already put
it t
Hi!
> Is it possible to use the default parameter on inheritance?
>
> class Bar {
> function foo($a='a', $b='b') {}
> }
>
> class Baz extends Bar {
> function foo($a=default, $b=default) {
> // do something
> parent::foo($a, $b);
> }
> }
It's not part of the original
Hi Stas,
As I said, we should look at that patch as we implemented Named Parameters
there with everything you mentioned.
Cheers,
On Wed, Jan 14, 2015 at 3:23 PM, Stanislav Malyshev
wrote:
> Hi!
>
> > -1 on this proposal
> >
> > +1 on named parameters
>
> Come on, we've already talked about it
Hi!
> -1 on this proposal
>
> +1 on named parameters
Come on, we've already talked about it like 20 times and it has special
paragraph in the RFC dedicated exactly to this. It's not instead named
params, we can do both.
> Pierrick and I both implemented this support for Annotations back in 2010
Hi,
-1 on this proposal
+1 on named parameters
As of for this...
> > handy and easier. I could dig the archives but I don't remember what
> > was the reason why we rejected the idea back then.
>
> Bikeshedding about the syntax mostly, but that all pales compared to
> amount of work that needs t
Am 14.01.2015 um 20:21 schrieb Adam Harvey:
On 14 January 2015 at 11:15, Marc Bennewitz wrote:
But I think adding "default" as new keyword is a big BC break!
Default already is a keyword: http://php.net/switch. There's no BC break.
OMG you are right - my fault
I personally also don't li
> On 15/01/2015, at 06:33, Marcio Almada wrote:
>
> Marc Bennewitz, Stas,
>
>> But I think adding "default" as new keyword is a big BC break!
>> I personally also don't like it and asked myself why can't the parameter
> simply skipped?
>
> Default is already a reserved word AFAIK. But I've bee
Marc Bennewitz, Stas,
> But I think adding "default" as new keyword is a big BC break!
> I personally also don't like it and asked myself why can't the parameter
simply skipped?
Default is already a reserved word AFAIK. But I've been thinking about
alternatives to parameter skipping syntax which
On 14 January 2015 at 11:15, Marc Bennewitz wrote:
> But I think adding "default" as new keyword is a big BC break!
Default already is a keyword: http://php.net/switch. There's no BC break.
> I personally also don't like it and asked myself why can't the parameter
> simply skipped?
That was in
Hi Stas,
I really like this RFC. It makes it simple to use defined defaults
without the need to know about them of to updated.
But I think adding "default" as new keyword is a big BC break!
I personally also don't like it and asked myself why can't the parameter
simply skipped?
function
Alexey Zakhlestin wrote:
PHPDoc doesn't support parameter blocks, which means that IDEs can't offer
>>the same level of assistance with code-completion that they offer for both
>>objects and straight parameters -- another huge downside.
>
>
>PHPDoc's does 'not' not support parameter blocks ... y
On Tue, Sep 3, 2013 at 11:47 AM, Lester Caine wrote:
> Robert Williams wrote:
>>
>> PHPDoc doesn't support parameter blocks, which means that IDEs can't offer
>> the same level of assistance with code-completion that they offer for both
>> objects and straight parameters -- another huge downside.
Robert Williams wrote:
PHPDoc doesn't support parameter blocks, which means that IDEs can't offer the
same level of assistance with code-completion that they offer for both objects
and straight parameters -- another huge downside.
PHPDoc's does 'not' not support parameter blocks ... you just
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
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
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
>>> 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
appreciate your RFC.
Best,
Robert
-Ursprüngliche Nachricht-
Von: Stas Malyshev [mailto:smalys...@sugarcrm.com]
Gesendet: Montag, 2. September 2013 22:12
An: Nikita Popov
Cc: PHP Internals
Betreff: Re: [PHP-DEV] [RFC] Skipping parameters take 2
Hi!
> I think this doesn't really
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!
> 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!
> 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
>
> > 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 :)
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
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
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, 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 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
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!
> 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
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
69 matches
Mail list logo
