I was about to respond to Lester's comments but it looks like Jeremiah beat
me to it (again). Yeah he's correct in that "bad habits" refers to using
Git the same way you would use Subversion. It was not mean to refer to how
you've used Subversion itself.
@David Generally, I would resolve this by
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/04/2012 10:32 AM, Jaroslav Hanslik wrote:
>>
>> (3) Karma system fixes. Already done by me. People who have
>> access to the root of a repository are able to do forced pushes.
>>
>
>
> Do you think it's good idea not to forbid forced pushes a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/04/2012 02:09 PM, Stefan Marr wrote:
> Hi David:
>
> On 03 Mar 2012, at 22:58, David Soria Parra wrote:
>
>> (1) Pull requests on github.com go to the git-pull mailinglist.
>> Make sure you subscribe to it. (2) Johannes is working on an
>> int
On Mar 4, 2012 11:47 AM, "Lazare Inepologlou" wrote:
>
>
> Anthony, just a tiny detail in your RCF:
>
>> So (int) $foo = null and (int) $foo = 1 are both supported, but (int)
$foo = “1” will generate an E_COMPILE_ERROR.
>
>
> If null is going to be cast, (int)null is 0. So I don't think it should
It would make sense that the default value you're setting matches the
zval.type of the casted value.
You always want it to be an int, if you're doing (int) so setting it
to a string or array would not make sense.
- Paul.
On Sun, Mar 4, 2012 at 4:46 PM, Lazare Inepologlou wrote:
> Anthony, just
Anthony, just a tiny detail in your RCF:
So (int) $foo = null and (int) $foo = 1 are both supported, but (int) $foo
> = “1” will generate an E_COMPILE_ERROR.
>
If null is going to be cast, (int)null is 0. So I don't think it should be
a valid default value.
Lazare INEPOLOGLOU
Ingénieur Logiciel
jeremiah.do...@gmail.com wrote:
I hope that clarifies things a bit. It definitely doesn't make grokking
things a whole lot easier, and it is certainly *possible* to follow a
very svnish workflow using git (and may sometimes make sense to,
although I am struggling to thing of such a time).
I've
Is (DateInterval) a valid cast currently in PHP ?
If not, then we're not looking to add new fancy casting options, just
give casting options on the simple existing ones.
- Paul.
On Sun, Mar 4, 2012 at 4:26 PM, Lazare Inepologlou wrote:
>> I wouldn't want people to put class typehints in there s
>
> I wouldn't want people to put class typehints in there such as
>
function foo( (SomeClass) $foo)
>
Why not? I would definitely like something like that, in the future. Here
is an example:
class DateTime {
...
public function add( (DateInterval) $interval ) { ... }
...
}
$date = new Date
Hi!
Could somebody with Zend karma please apply the patch attached to
https://bugs.php.net/bug.php?id=61273 ?
Thanks, Nikita
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Sun, 04 Mar 2012 15:02:23 +0100, Anthony Ferrara
wrote:
In sum, I think the rule that if a mathematical operation involves a
float, the result should be a float ought to be kept.
Yes, it is a must.
Well, I'm not so sure about that.
If you look at the docs of pow(), it describes the r
Stefan Marr writes:
> Hi David:
>
> On 03 Mar 2012, at 22:58, David Soria Parra wrote:
>
>> (1) Pull requests on github.com go to the git-pull mailinglist.
>> Make sure you subscribe to it.
>> (2) Johannes is working on an interface that allows people with
>> valid PHP user accounts to cl
Lester Caine writes:
> Kris Craig wrote:
>> I count myself lucky in that I started using Git before Subversion. People
>> with that background often have an easier time at first because they aren't
>> burdened with having to un-learn a bunch of "bad habits."
>
> I feel I HAVE to comment on that
Good.
On Sun, Mar 4, 2012 at 2:03 PM, Anthony Ferrara wrote:
>> Can you make sure that only scalar or array casts can be done?
>>
>> I wouldn't want people to put class typehints in there such as
>> function foo( (SomeClass) $foo)
>
> That's how it is implemented now. That'll generate a parse er
> Can you make sure that only scalar or array casts can be done?
>
> I wouldn't want people to put class typehints in there such as
> function foo( (SomeClass) $foo)
That's how it is implemented now. That'll generate a parse error...
--
PHP Internals - PHP Runtime Development Mailing List
To un
>> In sum, I think the rule that if a mathematical operation involves a float,
>> the result should be a float ought to be kept.
>
> Yes, it is a must.
Well, I'm not so sure about that.
If you look at the docs of pow(), it describes the return type as
"base raised to the power of exp. If the resu
Can you make sure that only scalar or array casts can be done?
I wouldn't want people to put class typehints in there such as
function foo( (SomeClass) $foo)
- Paul.
On Sun, Mar 4, 2012 at 1:28 AM, Anthony Ferrara wrote:
> Hey all,
>
> I've drafted an RFC for the Parameter type casting hint pro
On Sun, Mar 4, 2012 at 2:29 PM, Anthony Ferrara wrote:
> Hey all,
> [snip]
> https://bugs.php.net/bug.php?id=60596
> A little code-cleanup to remove a superfluous if statement in a switch
> in the spl_offset_convert_to_long function...
Applied in http://svn.php.net/viewvc/?view=revision&revision=3
On Sun, Mar 4, 2012 at 2:52 PM, Gustavo Lopes wrote:
> In sum, I think the rule that if a mathematical operation involves a float,
> the result should be a float ought to be kept.
Yes, it is a must.
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PH
On Sun, 04 Mar 2012 14:29:49 +0100, Anthony Ferrara
wrote:
I had messaged about these patches before, but with the 5.4 release
process happening I think it slipped through the cracks. I have 3
patches that are ready for inclusion...
[...]
https://bugs.php.net/bug.php?id=60789
Bringing pow
The vote ended with 23 pro / 4 con.
The /e modifier is now deprecated in trunk:
http://svn.php.net/viewvc?view=revision&revision=323862
Nikita
On Sun, Feb 12, 2012 at 7:34 PM, Nikita Popov wrote:
> As there doesn't seem to be any further discussion regarding this
> issue I have opened the vote:
Hey all,
I had messaged about these patches before, but with the 5.4 release
process happening I think it slipped through the cracks. I have 3
patches that are ready for inclusion...
https://bugs.php.net/bug.php?id=60813
Adding a new hash_pbkdf2() function to allow for a C level
implementation o
Hi David:
On 03 Mar 2012, at 22:58, David Soria Parra wrote:
> (1) Pull requests on github.com go to the git-pull mailinglist.
> Make sure you subscribe to it.
> (2) Johannes is working on an interface that allows people with
> valid PHP user accounts to close pull requests.
> (2) Fix the
Kris Craig wrote:
I count myself lucky in that I started using Git before Subversion. People
with that background often have an easier time at first because they aren't
burdened with having to un-learn a bunch of "bad habits."
I feel I HAVE to comment on that statement. A 'different way of wor
+1 what Jeremiah said!
I've noticed that people who are accustomed to Subversion tend to go into
Git using the SVN branching mindset. While that does technically work in
Git, it essentially misses the point. To illustrate, let's say a person
from the 16th century travelled forward through time t
(3) Karma system fixes. Already done by me. People who have access to
the root of a repository are able to do forced pushes.
Do you think it's good idea not to forbid forced pushes at all?
Cheers
Jaroslav
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
26 matches
Mail list logo
