On 02/19/2013 11:22 PM, Klaus Ufo wrote:
Hi there !
We all know that the current PHP API has flaws. Maybe we could use namespaces
to build a new coherent PHP API ? Like :
- \arr
- \num
- \str
and so on. Advantages :
- no more global functions
- separation of concerns
- backward compatibili
Hi there !
We all know that the current PHP API has flaws. Maybe we could use namespaces
to build a new coherent PHP API ? Like :
- \arr
- \num
- \str
and so on. Advantages :
- no more global functions
- separation of concerns
- backward compatibility
- work can be done progressively
- easy to
Hi,
I've forked out an interesting project on Github that implements XXHash and
extended it to work with the hash() function family. Project links below.
The integration is pretty straightforward, but the following code had me
concerned:
PHP_HASH_API void PHP_XXH32Update(PHP_XXH32_CTX *context,
On Tue, Feb 19, 2013 at 8:06 PM, Sara Golemon wrote:
> Opening RFC to allow trailing comma in function call argument lists
>
> https://wiki.php.net/rfc/trailing-comma-function-args
-1 on this.
I really don't like this, it look very weird, and the gain is minor.
thanks
>
> --
> PHP Internals -
On Tue, Feb 19, 2013 at 7:06 AM, Sara Golemon wrote:
> Opening RFC to allow trailing comma in function call argument lists
>
> https://wiki.php.net/rfc/trailing-comma-function-args
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
On 02/19/2013 03:08 PM, Terry Ellison wrote:
I guess that I should bite the bullet and switch to 5.5.
Yes.
I've been working on an evaluatorfork of APC optimized for CLI/GCI
which tackles a lot of these issues head on and performs reasonable
well, but I realise that this is a dead-end and w
On Feb 19, 2013, at 6:01 PM, Zeev Suraski wrote:
> Are we really trying to look under ground now for ways to change the
> language syntax?
Agree 100%. Not to mention, I plan on eventually convincing enough people to
replace that keyword with a type hint ;)
>
> Unless there's a strong case to
Stas Malyshev in php.internals (Tue, 19 Feb 2013 15:35:54 -0800):
>> Johannes Schlüter in php.internals (Thu, 31 Jan 2013 16:00:17 +0100):
>>> If no critical issues is found in this RC, the final version will be
>>> released in two weeks.
>>
>> Just curious: what is keeping 5.3.22 and 5.4.12 from
On Tue, 2013-02-19 at 17:08 -0700, Levi Morrison wrote:
> Let's stop pretending that the vast majority of PHP users actually
> grep source code looking for `function foo`.
That was never said, but there's a big number of people who has to deal
with code produced by others and doing tasks where it
> Let's stop pretending that the vast majority of PHP users actually
> grep source code looking for `function foo`. They don't. *They don't
> even know how to use grep.*
I don't grep as in `grep`, but as in "regex search that is part of my
IDE but is not also tokenizing/whateverizing/PHP-aware."
> Protip: use an IDE.
Linux is my IDE.
--
Herman Radtke
@hermanradtke | http://hermanradtke.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
>> The key question for me is: does removing it hurt PHP in any way? And
>> for me, the answer is a clear and resounding no. I do not grep code
>> for method definitions: I know exactly where they are and so will my
>> IDE if I happen to not be using vim. And for those who like to grep
>> for metho
> I am something of a language guru and to me syntax is *extremely*
> important. Am I of the opinion that removing the function keyword from
> the class definition will help? Yes, I am.
I'm missing the help. It saves 9 characters and creates a disjunction
between global function syntax and functi
On Tue, 19 Feb 2013 03:07:37 +0100, Stas Malyshev
wrote:
If no one objects, I'll merge this into 5.5 and master:
https://github.com/cataphract/php-src/compare/dval_to_lval
Maybe add UNEXPECTED around the if condition? Since it's marked as
zend_always_inline I imagine it's supposed to be pe
On 02/19/2013 03:45 PM, Levi Morrison wrote:
> The key question for me is: does removing it hurt PHP in any way? And
> for me, the answer is a clear and resounding no. I do not grep code
> for method definitions: I know exactly where they are and so will my
> IDE if I happen to not be using vim. A
On Tue, Feb 19, 2013 at 4:01 PM, Zeev Suraski wrote:
> Are we really trying to look under ground now for ways to change the
> language syntax?
>
> Unless there's a strong case to adding/removing/changing syntax, that
> goes well beyond 'because we can' or 'it shortens the code' it
> shouldn't even
Hi,
On Sat, 2013-02-16 at 19:46 +0100, Pierre Schmitz wrote:
> Hi,
>
> our default PHP package includes pdo_mysql as a shared module. Creating
> a debug build with the same configuration seems to be impossible due to
> bug #60840. This bug was closed as "Not a bug" but it is not clear how
> this
Hi!
> Johannes Schlüter in php.internals (Thu, 31 Jan 2013 16:00:17 +0100):
>> If no critical issues is found in this RC, the final version will be
>> released in two weeks.
>
> Just curious: what is keeping 5.3.22 and 5.4.12 from being released?
> Are there any issues?
We had 5.4.12 RC2 last we
On Wed, 2013-02-20 at 00:13 +0100, Jan Ehrhardt wrote:
> Johannes Schlüter in php.internals (Thu, 31 Jan 2013 16:00:17 +0100):
> >If no critical issues is found in this RC, the final version will be
> >released in two weeks.
>
> Just curious: what is keeping 5.3.22 and 5.4.12 from being released?
On Tue, 19 Feb 2013 13:01:18 +0100, Derick Rethans wrote:
On Fri, 15 Feb 2013, Sanford Whiteman wrote:
I think it was done to ease adoption even though it was known to
violate LSP. To quote Stas, "As for established practice, everybody
expects DateTime, so IMHO we should leave DateTime as bas
2013/2/19 Nikita Nefedov :
> Hmm, I agree about grepping, but how often do you do it? Actually, last time
> I grepped php files was half a year ago I think, when I had just ssh
> connection and didn't want to mount sshfs. But usually there's IDEs that can
> statically analyze your code and let you
Johannes Schlüter in php.internals (Thu, 31 Jan 2013 16:00:17 +0100):
>If no critical issues is found in this RC, the final version will be
>released in two weeks.
Just curious: what is keeping 5.3.22 and 5.4.12 from being released?
Are there any issues?
Jan
--
PHP Internals - PHP Runtime Devel
On 19/02/13 20:32, Stas Malyshev wrote:
Hi!
and IIRC mwiki does 4 of these on a page render. Here a pattern based
on (@include($file) == 1) is more cache-friendly.
This goes back to the fact that @ does not really disable errors - it
only disables reporting of the errors, but the whole messag
Are we really trying to look under ground now for ways to change the
language syntax?
Unless there's a strong case to adding/removing/changing syntax, that
goes well beyond 'because we can' or 'it shortens the code' it
shouldn't even be brought up for discussion.
Zeev
On 19 בפבר 2013, at 19:44,
Kalle Sommer Nielsen in php.internals (Tue, 19 Feb 2013 22:27:42 +0100):
>Den 19/02/2013 kl. 19.48 skrev Kris Craig :
>
>> Somebody filed a bug report (https://bugs.php.net/bug.php?id=64154) about
>> non-bundled extensions like php_zip being included in php.ini. Is there a
>> reason why we're keep
Seems this would complicate the transplanting of (global) functions
into (default public) class methods and vice versa. This is a common
refactoring task -- at least IME -- and before I adjust visibility I
would expect the function to Just Work.
So this works in a class to define the function:
fu
Den 19/02/2013 kl. 19.48 skrev Kris Craig :
> Hey guys,
>
> Somebody filed a bug report (https://bugs.php.net/bug.php?id=64154) about
> non-bundled extensions like php_zip being included in php.ini. Is there a
> reason why we're keeping those in there, or is it just that nobody ever got
> around
On 20 February 2013 00:12, Nikita Nefedov wrote:
> On Tue, 19 Feb 2013 19:10:22 -, Rasmus Lerdorf
> wrote:
>
>> On 02/19/2013 03:07 PM, Nikita Nefedov wrote:
>>
>>> Are you grepping for all the functions or you are grepping just for some
>>> specific function? If so, you are likely already kn
On Tue, 2013-02-19 at 23:07 +, Nikita Nefedov wrote:
>
> At the end, you can always use `grep '(function|public|private|
> protected)
You've forgotten "abstract" and "static" (mind that we don't force the
order of those)
It saves 9 key strokes (while many IDEs can assist) and helps when
lo
Hi!
> and IIRC mwiki does 4 of these on a page render. Here a pattern based
> on (@include($file) == 1) is more cache-friendly.
This goes back to the fact that @ does not really disable errors - it
only disables reporting of the errors, but the whole message is
generated and goes all the cycle u
Hi Stas,
I'll take a look tomorrow or after tomorrow.
Sorry, quite busy.
Thanks. Dmitry.
On Tue, Feb 19, 2013 at 1:23 PM, Stas Malyshev wrote:
> Hi!
>
> I've created a pull to fix bug 49348 - when undefined properties do not
> produce a notice when doing something like $this->undefined++, unlik
On Tue, 19 Feb 2013 19:10:22 -, Rasmus Lerdorf
wrote:
On 02/19/2013 03:07 PM, Nikita Nefedov wrote:
Are you grepping for all the functions or you are grepping just for some
specific function? If so, you are likely already know what visibility
this function has, so couldn't you grep for
On 02/19/2013 03:07 PM, Nikita Nefedov wrote:
> Are you grepping for all the functions or you are grepping just for some
> specific function? If so, you are likely already know what visibility
> this function has, so couldn't you grep for `public %functionName%`
> instead of `function %functionNam
On Tue, 19 Feb 2013 18:02:57 -, Christopher Jones
wrote:
What about including a few basic examples aka test cases in your patch?
If the feature is accepted, you'll need to include a LOT of testcases.
Chris
Hi Chris,
this code could be a basic case (just for the sake of understandi
On Tue, Feb 19, 2013 at 11:53 AM, Lester Caine wrote:
> Rasmus Lerdorf wrote:
>>
>> On 02/19/2013 02:39 PM, Nikita Nefedov wrote:
>>>
>>> >Hmm, I agree about grepping, but how often do you do it? Actually, last
>>> >time I grepped php files was half a year ago I think, when I had just
>>> >ssh con
Rasmus Lerdorf wrote:
On 02/19/2013 02:39 PM, Nikita Nefedov wrote:
>Hmm, I agree about grepping, but how often do you do it? Actually, last
>time I grepped php files was half a year ago I think, when I had just
>ssh connection and didn't want to mount sshfs. But usually there's IDEs
>that can s
Hey guys,
Somebody filed a bug report (https://bugs.php.net/bug.php?id=64154) about
non-bundled extensions like php_zip being included in php.ini. Is there a
reason why we're keeping those in there, or is it just that nobody ever got
around to removing them?
Thanks!
--Kris
On 02/19/2013 02:39 PM, Nikita Nefedov wrote:
> Hmm, I agree about grepping, but how often do you do it? Actually, last
> time I grepped php files was half a year ago I think, when I had just
> ssh connection and didn't want to mount sshfs. But usually there's IDEs
> that can statically analyze you
On Tue, 19 Feb 2013 17:53:40 -, Johannes Schlüter
wrote:
I agreed to the conclusion that the "function" keyword provided a nice
way to grep for functions when handling foreign code and leaving it out
only provides little improvement in less typing.
Please provide new arguments for a new
On 02/19/2013 09:45 AM, Marcello Duarte wrote:
And "just for you" is also inaccurate. You will find that the
technologies I've been referring to are becoming the tools you will
use for DevOps, etc... tasks. Do you guys listen to people outside
of internals? It would be good to have a feedback
On 19.02.2013 13:06, Sara Golemon wrote:
> Opening RFC to allow trailing comma in function call argument lists
>
> https://wiki.php.net/rfc/trailing-comma-function-args
>
For completeness' sake:
The VCS argument is kind of moot if you format your source code like
it's sometimes/often seen in Has
@Marcello: actually, I am also of the idea that there's no real additional
value in such a syntax...
Since I'm using ZF2 (yeah, that framework that converts array to
applications) I am kinda used to have dozens of `function () {}` closures
for service factories: so far no problems with it.
As sta
Hi,
On Tue, 2013-02-19 at 21:44 +, Nikita Nefedov wrote:
> Hi!
>
> As someone mentioned in the thread about short syntax for closures, we
> could also drop requirement for `function` keyword when defining/declaring
> methods in classes, interfaces or traits.
I proposed this in November '
> I've created a pull to fix bug 49348 - when undefined properties do not
> produce a notice when doing something like $this->undefined++, unlike
> regular variables that do.
I've been bitten by this from time to time. A notice would have been nice.
--
PHP Internals - PHP Runtime Development Mai
On 19 Feb 2013, at 17:32, Leigh wrote:
>
> On 19 February 2013 16:46, Marcello Duarte wrote:
> I find that more and more my developers have to learn ruby just to be able to
> work in our projects. We are one of the largest PHP shops in Europe and even
> the proprietary tools we are writing for
Hi!
As someone mentioned in the thread about short syntax for closures, we
could also drop requirement for `function` keyword when defining/declaring
methods in classes, interfaces or traits.
I have long noticed how redundant it is. The patch is pretty easy as it
was with commas :)
It is
>> a) The DateTimeImmutable class extends the DateTime class. Why was
>> this done this way? Both classes are incompatible (as in the
>> inheritance violates LSP). E.g. if you hint against DateTime, then
>> passing in DateTimeImmutable will not work (as the behavior is
>> different). The same also
>> > I think the warning can stay as-is, __toString is not necessarily
>> > available so casting to string in all occasions is probably not what
>> > we want.
>>
>> I think it should cast to a string if possible. You are now making
>> iterator_to_array not work with the new feature, and I find that
On 19 February 2013 16:46, Marcello Duarte wrote:
> I find that more and more my developers have to learn ruby just to be able
> to work in our projects. We are one of the largest PHP shops in Europe and
> even the proprietary tools we are writing for DevOps stuff we are writing
> in Ruby. This s
> Have you considered how this will work/look in an array?
>
> $a = [$b => ($n) $m => $m * $n]; // wat.
First off, it should be:
$a = [$b => ($n) |$m| => $m * $n];
The || make a big difference in this situation.
Secondly, if you hit a situation where the syntax is confusing, use a
less conf
On Tue, Feb 19, 2013 at 6:40 PM, Levi Morrison wrote:
> > Say we agree on the syntax above
> >> ($n) |$m| => $m * $n;
> > What happens when my one liner function needs to do one more operation
> > like checking the value of $n before multiplication?
>
> As I stated before suggesting the syntax: It
On 19 Feb 2013, at 14:16, Leigh wrote:
>>
>>
>> I can understand that If you haven't tried to write a tool like
>> capistrano, rspec, chef, puppet, etc, etc in PHP you probably won't see
>> much value in implementing such things.
>>
>>
> Your RFC doesn't go to great lengths to explain the valu
>> Say we agree on the syntax above
>>> ($n) |$m| => $m * $n;
>> What happens when my one liner function needs to do one more operation
>> like checking the value of $n before multiplication?
>
> As I stated before suggesting the syntax: It's only meant for a single
> expression. It's purposefully
> Say we agree on the syntax above
>> ($n) |$m| => $m * $n;
> What happens when my one liner function needs to do one more operation
> like checking the value of $n before multiplication?
As I stated before suggesting the syntax: It's only meant for a single
expression. It's purposefully NOT inten
On Tue, 19 Feb 2013 16:31:39 -, Marcello Duarte
wrote:
On 19 Feb 2013, at 16:29, Morfi wrote:
($n) => { echo $n; }
($n) use ($m) => { echo $n; }
Morfi, the problem pointed out already is when you have no arguments it
would be the same as the statement block, which would cause BC iss
On 19 Feb 2013, at 16:29, Morfi wrote:
> ($n) => { echo $n; }
> ($n) use ($m) => { echo $n; }
Morfi, the problem pointed out already is when you have no arguments it would
be the same as the statement block, which would cause BC issues.
> On Tue, Feb 19, 2013 at 8:11 PM, Levi Morrison wrote:
>
($n) => { echo $n; }
($n) use ($m) => { echo $n; }
On Tue, Feb 19, 2013 at 8:11 PM, Levi Morrison wrote:
> > IF (and I stress if) we add a a shorter anonymous function syntax I'd
> > like it to be geared towards one-liners because that's where the
> > current syntax feels really verbose, especial
Hello,
On Tue, Feb 19, 2013 at 6:09 PM, Levi Morrison wrote:
> There's already been an overwhelming negative reaction to this
> particular proposed syntax so I won't belabor the point much. In
> short, this is too similar to block statements and does have BC
> issues.
>
> --
>
> IF (and I stress
> IF (and I stress if) we add a a shorter anonymous function syntax I'd
> like it to be geared towards one-liners because that's where the
> current syntax feels really verbose, especially when you close over
> other variables:
>
> function ($n) use ($m) { return $m * $n; }
>
> Versus one poten
There's already been an overwhelming negative reaction to this
particular proposed syntax so I won't belabor the point much. In
short, this is too similar to block statements and does have BC
issues.
--
IF (and I stress if) we add a a shorter anonymous function syntax I'd
like it to be geared to
On 19/02/13 09:36, Terry Ellison wrote:
The point that this thread highlights is that apps developers /
administrators at both ends of the scale -- the enterprise and the
shared service user -- normally have little say over the
infrastructure architecture on which their application runs. In bo
On Feb 19, 2013, at 8:00 AM, Sara Golemon wrote:
> On Tue, Feb 19, 2013 at 4:41 AM, Kingsquare.nl - Robin Speekenbrink
> wrote:
>> Just a question from one of the lingering listeners: would this change also
>> ease the `skipping` of default values for parameters? (as discussed for RFC
>> https:
+1
On 19 February 2013 07:06, Sara Golemon wrote:
> Opening RFC to allow trailing comma in function call argument lists
>
> https://wiki.php.net/rfc/trailing-comma-function-args
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
+1
On Feb 19, 2013 10:13 AM, "Cyberspice" wrote:
> On 19 Feb 2013, at 12:06, Sara Golemon wrote:
>
> > Opening RFC to allow trailing comma in function call argument lists
> >
> > https://wiki.php.net/rfc/trailing-comma-function-args
>
> +1
>
> Melanie
>
>
> --
> PHP Internals - PHP Runtime Deve
On 19 Feb 2013, at 12:06, Sara Golemon wrote:
> Opening RFC to allow trailing comma in function call argument lists
>
> https://wiki.php.net/rfc/trailing-comma-function-args
+1
Melanie
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.ph
I also don't like the RFC proposed syntax. I have to say that I don't
really like those short magic-like syntax things in in other languages too.
If you work with them on the day-to-day basis and tools are built around
those concepts - it's one thing. In PHP syntax is mostly self-explanatory
and fo
>
>
> I can understand that If you haven't tried to write a tool like
> capistrano, rspec, chef, puppet, etc, etc in PHP you probably won't see
> much value in implementing such things.
>
>
Your RFC doesn't go to great lengths to explain the value either. Pretend
the reader has no experience with a
On Tue, Feb 19, 2013 at 2:55 PM, Derick Rethans wrote:
> Gah, no top posting!
>
> On Tue, 19 Feb 2013, Etienne Kneuss wrote:
>
> > On Tue, Feb 19, 2013 at 2:25 PM, Derick Rethans wrote:
> >
> > > On Tue, 19 Feb 2013, Nikita Popov wrote:
> > >
> > > > This RFC proposes to remove the type-restrict
Hi Marcello,
Am 19.02.2013 um 14:51 schrieb Marcello Duarte :
> Thanks for the feedback. I get most people here don't appreciate the value of
> the feature.
>
> I can understand that If you haven't tried to write a tool like capistrano,
> rspec, chef, puppet, etc, etc in PHP you probably won't
Gah, no top posting!
On Tue, 19 Feb 2013, Etienne Kneuss wrote:
> On Tue, Feb 19, 2013 at 2:25 PM, Derick Rethans wrote:
>
> > On Tue, 19 Feb 2013, Nikita Popov wrote:
> >
> > > This RFC proposes to remove the type-restrictions on Iterator keys
> > > used in foreach:
> > >
> > > https://wiki.p
Thanks for the feedback. I get most people here don't appreciate the value of
the feature.
I can understand that If you haven't tried to write a tool like capistrano,
rspec, chef, puppet, etc, etc in PHP you probably won't see much value in
implementing such things.
On 19 Feb 2013, at 13:19, D
Hello,
On Tue, Feb 19, 2013 at 2:57 PM, Marcello Duarte wrote:
> Inspired by Sara, here is another RFC, I finally got around to draft:
>
> https://wiki.php.net/rfc/short-syntax-for-anonymous-function
>
> Please feedback,
> --
> Marcello Duarte
>
I really don't like syntax for this. It makes it h
Sara,
I wasnt commenting that this RFC was different, just in agreement that this
syntax is _more_ in line with the list() construct (which then might
reflect the skipparams rfc))
If i wasnt clear: from a user point of view: i am all for this RFC ;)
Met vriendelijke groet,
Robin Speekenbrink
Kin
I think the warning can stay as-is, __toString is not necessarily available
so casting to string in all occasions is probably not what we want.
I'm glad somebody could take this over and provide a complete patch, thanks
Nikita!
On Tue, Feb 19, 2013 at 2:25 PM, Derick Rethans wrote:
> On Tue, 1
Hi,
I don't really like to write every time a "long" 'function()', only for passing
a little callback like 'function ($v) { var_dump($v); }'...:
Nice proposal, but writing the last argument outside of the function call could
be confusing... An user-function is not a language construct (like whi
On Tue, Feb 19, 2013 at 2:25 PM, Derick Rethans wrote:
> On Tue, 19 Feb 2013, Nikita Popov wrote:
>
> > This RFC proposes to remove the type-restrictions on Iterator keys
> > used in foreach:
> >
> > https://wiki.php.net/rfc/foreach-non-scalar-keys
> >
> > I took over Levi's RFC and added a patch
2013/2/19 Marcello Duarte :
> Inspired by Sara, here is another RFC, I finally got around to draft:
>
> https://wiki.php.net/rfc/short-syntax-for-anonymous-function
>
> Please feedback,
> --
> Marcello Duarte
BC break detected:
The {} would probably be a closure that is not assigned to anything
On Tue, 19 Feb 2013, Nikita Popov wrote:
> This RFC proposes to remove the type-restrictions on Iterator keys
> used in foreach:
>
> https://wiki.php.net/rfc/foreach-non-scalar-keys
>
> I took over Levi's RFC and added a patch for it.
Under "Open Questions" you write:
> What should be done wi
I also am not in favour of the syntax, it's too short and quirky. I'm
honestly fine with 'function()' it's very explicit
On Tue, Feb 19, 2013 at 1:20 PM, Anthony Ferrara wrote:
> Marcello,
>
>
> On Tue, Feb 19, 2013 at 7:57 AM, Marcello Duarte
> wrote:
>
> > Inspired by Sara, here is another RF
On 19 February 2013 13:57, Marcello Duarte wrote:
> Inspired by Sara, here is another RFC, I finally got around to draft:
>
> https://wiki.php.net/rfc/short-syntax-for-anonymous-function
>
> Please feedback,
>
>
Duh, I don't think function(){} is long.
--
Regards,
Mike
Marcello,
On Tue, Feb 19, 2013 at 7:57 AM, Marcello Duarte wrote:
> Inspired by Sara, here is another RFC, I finally got around to draft:
>
> https://wiki.php.net/rfc/short-syntax-for-anonymous-function
>
> Please feedback,
> --
> Marcello Duarte
>
>
I like the concept. I dislike the syntax. It
On Tue, 19 Feb 2013, Marcello Duarte wrote:
> Inspired by Sara, here is another RFC, I finally got around to draft:
>
> https://wiki.php.net/rfc/short-syntax-for-anonymous-function
I'd be really reluctant to add this -- it's yet another (superfluous)
syntactical sugar, there is no patch, and ho
Hi internals!
This RFC proposes to remove the type-restrictions on Iterator keys used in
foreach:
https://wiki.php.net/rfc/foreach-non-scalar-keys
I took over Levi's RFC and added a patch for it.
Thoughts?
Nikita
Inspired by Sara, here is another RFC, I finally got around to draft:
https://wiki.php.net/rfc/short-syntax-for-anonymous-function
Please feedback,
--
Marcello Duarte
On Tue, Feb 19, 2013 at 4:41 AM, Kingsquare.nl - Robin Speekenbrink
wrote:
> Just a question from one of the lingering listeners: would this change also
> ease the `skipping` of default values for parameters? (as discussed for RFC
> https://wiki.php.net/rfc/skipparams)
>
> That way it would be con
Just a question from one of the lingering listeners: would this change also
ease the `skipping` of default values for parameters? (as discussed for RFC
https://wiki.php.net/rfc/skipparams)
That way it would be consistent with this RFC and the list() construct ?
With regards,
Robin Speekenbrink
2013/2/19 Sara Golemon :
> Opening RFC to allow trailing comma in function call argument lists
>
> https://wiki.php.net/rfc/trailing-comma-function-args
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
I'm all for it! Waiting for t
On Tue, Feb 19, 2013 at 1:06 PM, Sara Golemon wrote:
> Opening RFC to allow trailing comma in function call argument lists
>
> https://wiki.php.net/rfc/trailing-comma-function-args
looks good and consistent enough, you have my vote :)
--
Pierre
@pierrejoye
--
PHP Internals - PHP Runtime Dev
On Tue, 19 Feb 2013, Sara Golemon wrote:
> Opening RFC to allow trailing comma in function call argument lists
>
> https://wiki.php.net/rfc/trailing-comma-function-args
+1
cheers,
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.ph
Opening RFC to allow trailing comma in function call argument lists
https://wiki.php.net/rfc/trailing-comma-function-args
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Fri, 15 Feb 2013, Sanford Whiteman wrote:
> I think it was done to ease adoption even though it was known to
> violate LSP. To quote Stas, "As for established practice, everybody
> expects DateTime, so IMHO we should leave DateTime as base class even
> though it's not strictly OO-pure."
>
> Th
On Fri, 15 Feb 2013, Nikita Popov wrote:
> for PHP 5.5 a new DateTimeImmutable class was introduced, which is a
> variant of DateTime, which has methods working on a clone of the
> original object.
>
> There was no RFC on this and some of the design decisions are a bit
> uncleared to me, so I
Hi Internals after quite a long time,
There is an issue in the tracker (#61033 and somewhat related #64239)
about magic constants behaviour in aliased trait methods. Stefan
classified #61033 as a "feature not a bug" however he suggested to start
a discussion about it.
So here's the case: how
The point that this thread highlights is that apps developers /
administrators at both ends of the scale -- the enterprise and the
shared service user -- normally have little say over the infrastructure
architecture on which their application runs. In both these cases the
infrastructure will b
On Tue, Feb 19, 2013 at 4:23 AM, Stas Malyshev wrote:
> Hi!
>
> I've created a pull to fix bug 49348 - when undefined properties do not
> produce a notice when doing something like $this->undefined++, unlike
> regular variables that do.
>
> Unfortunately, this fix seems to require changing signatu
Hi!
I've created a pull to fix bug 49348 - when undefined properties do not
produce a notice when doing something like $this->undefined++, unlike
regular variables that do.
Unfortunately, this fix seems to require changing signature of
get_property_ptr_ptr(), adding fetch type, which makes it imp
96 matches
Mail list logo
