On Fri, Mar 9, 2012 at 3:58 AM, Ilia Alshanetsky wrote:
> Anthony,
>
> My concern with this type of patch is that what you are proposing are
> not really hints, they are forced casts. As such they modify the data
> potentially leading to data loss.
This patch specifically tries to overcome this pr
Anthony Ferrara wrote:
So, what do you think?
I am a big fan of this style. Accepting e.g. "1abc" as int(1) with a
notice seems like a better solution than anything else. A full error
would be too much towards strict typing (I wouldn't mind personally, but
others do have a strong opinion on
On Fri, Mar 9, 2012 at 10:58 AM, Ilia Alshanetsky wrote:
> Anthony,
>
> My concern with this type of patch is that what you are proposing are
> not really hints, they are forced casts. As such they modify the data
> potentially leading to data loss.
>
But at least it's consistent with "array" and
From: Adam Jon Richardson [mailto:adamj...@gmail.com]
> I don't think it's fair to say that casting is too forgiving OR
> that current sentiment is settling around behavior similar to the
> internal zend_parse_parameters. This is a complex issue, and there
> are many core developers who have been
Anthony,
My concern with this type of patch is that what you are proposing are
not really hints, they are forced casts. As such they modify the data
potentially leading to data loss.
On Thu, Mar 8, 2012 at 9:32 PM, Anthony Ferrara wrote:
> Hey all,
>
> As promised, I've created a POC patch to im
Actually, it turns out the segfault and auto-reference bugs were
easier than I thought to fix. I've updated both gists with the new
code, and it looks to be running quite well...
On Thu, Mar 8, 2012 at 9:32 PM, Anthony Ferrara wrote:
> Hey all,
>
> As promised, I've created a POC patch to implem
Actually, it turns out the segfault and auto-reference bugs were
easier than I thought to fix. I've updated both gists with the new
code, and it looks to be running quite well...
On Thu, Mar 8, 2012 at 9:32 PM, Anthony Ferrara wrote:
> Hey all,
>
> As promised, I've created a POC patch to implem
Hey all,
As promised, I've created a POC patch to implement scalar type hints,
the way that zend_parse_parameters handles hinting. First off, here's
the patch:
Directly apply-able without re2c:
https://gist.github.com/2004623
Removing generated files (requires re2c to compile):
https://gist.git
On Thu, Mar 8, 2012 at 6:08 PM, John Crenshaw wrote:
>
> > Well, if your type hints gets more forgiving, than it's the same that was
> > proposed by this function a((int) $arg) {} And in this case hints have no
> > meaning at all - it's just other syntax to do the conversion that now
> looks
> > l
On 03/08/2012 05:05 PM, Adam Harvey wrote:
Agreed. I'm happy to mark them as XFAIL if that's what's expected. Mike?
Adam
If the 5.4 behavior is deemed correct for 5.4+, then the expected output
should be updated for 5.4+ tests - they should not be XFAIL.
The UPGRADING file, migration doc,
On 9 March 2012 00:11, Remi Collet wrote:
> Le 08/03/2012 09:03, Michael Wallner a écrit :
>> Sorry for the delay, but I already explained the issue in
>> the bug report: https://bugs.php.net/bug.php?id=61291
>
> Thanks, for the explanation.
I'm still concerned about the idea that the output of a
> Well, if your type hints gets more forgiving, than it's the same that was
> proposed by this function a((int) $arg) {} And in this case hints have no
> meaning at all - it's just other syntax to do the conversion that now looks
> like this function a($arg) { $arg = (int)$arg; }
>
That's black a
On Thu, 08 Mar 2012 17:51:34 +0100, Michael Morris
wrote
I also don't understand your template argument. Why would you need to
namespace templates? Typically they are included from inside a function
(and therefore don't change/access the global namespace).
You forget that variable scope a
2012/3/8 Sebastian Bergmann :
> Am 08.03.2012 17:05, schrieb Michael Morris:
>> Thoughts?
>
> Sounds pointless/useless to me.
>
> --
> Sebastian Bergmann Co-Founder and Principal Consultant
> http://sebastian-bergmann.de/ http://thePHP.cc/
>
> --
> PHP
2012/3/8 Sebastian Bergmann :
> Am 08.03.2012 17:05, schrieb Michael Morris:
>> Thoughts?
>
> Sounds pointless/useless to me.
>
> --
> Sebastian Bergmann Co-Founder and Principal Consultant
> http://sebastian-bergmann.de/ http://thePHP.cc/
>
> --
> PHP
On Thu, Mar 8, 2012 at 5:30 PM, Sebastian Bergmann wrote:
> Am 08.03.2012 17:05, schrieb Michael Morris:
>> Thoughts?
>
> Sounds pointless/useless to me.
Could you answer more than one liner to RFCs? Even if you totally
disagree with the idea(s) behind it. Thanks.
Cheers,
--
Pierre
@pierrejoy
2012/3/8 Remi Collet
>
> But mhash_001.phpt and mhash_003.phpt should not fail
> (if we want a great PHP with 0 test failed).
>
Hi, all
That's what I would like to have ...
It would be perfect if new versions were not brought out if some tests
still fail.
I read some posts in the past before I
Am 08.03.2012 17:05, schrieb Michael Morris:
> Thoughts?
Sounds pointless/useless to me.
--
Sebastian BergmannCo-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
--
PHP Internals - PHP Runtime Development Mailing Li
At first glance, this is technically impossible, with regards to our
current resolution rules:
http://php.net/manual/en/language.namespaces.rules.php
Assuming you have an un-namespaced:
class Db {
public function __construct() {
$this->conn = new PDO(..);
}
}
and you require this as:
Michael,
Quick question: how would this work with require_once?
Let's say that I have a class Foo defined in a file without a
namespace declaration.
What happens if I require_once with a namespace first (so Foo gets
imported into the namespace), and then require_once later without a
namespace?
On Thu, 08 Mar 2012 17:05:19 +0100, Michael Morris
wrote:
https://wiki.php.net/rfc/changes_to_include_and_require
Since the reaction to the first of the two suggestions was largely
negative I've withdrawn it for now to focus on the second of the two
changes. In all honestly, these two sugge
Le 08/03/2012 09:03, Michael Wallner a écrit :
> On Mon, 05 Mar 2012 17:52:52 +0100, Remi Collet wrote:
>
>>
>> Using a simple C program (linked against libmash)
>>
>> Hash: fdb9019a79c33a95677e2097abae91eb0de00b3054bb5c39
>>
>> So the result from php <= 5.3.10 seems the right one.
>
> Sorry for
https://wiki.php.net/rfc/changes_to_include_and_require
Since the reaction to the first of the two suggestions was largely
negative I've withdrawn it for now to focus on the second of the two
changes. In all honestly, these two suggestions should have had
independent RFC's from the start.
Of the
Gustavo,
> Not really, that's just a convention that if zpp fails functions return null
> or false immediately (which one is used depends on the extension, current
> weather, etc.). That's because there's a convention that builtin functions
> don't raise exceptions. But nothings stops them from fa
2012/3/8 John Crenshaw :
> From: Arvids Godjuks [mailto:arvids.godj...@gmail.com]
>> That's why I described the rules when type juggling comes into play.
>> If you send a string number, it is converted from string to number by the
>> type hint. If you send a string of characters and pass it to a i
On Thu, 08 Mar 2012 13:38:32 +0100, Anthony Ferrara
wrote:
AFAIR Gustavo, Anthony and Nikic discussed on IRC, that maybe the best
solution for scalar type hints would be the unification of the scalar
type
hints with the current implementation of zend_parse_parameters.
Yeah, that's basica
> AFAIR Gustavo, Anthony and Nikic discussed on IRC, that maybe the best
> solution for scalar type hints would be the unification of the scalar type
> hints with the current implementation of zend_parse_parameters.
Yeah, that's basically what we were discussing. However, there's one
significant
From: Arvids Godjuks [mailto:arvids.godj...@gmail.com]
> That's why I described the rules when type juggling comes into play.
> If you send a string number, it is converted from string to number by the
> type hint. If you send a string of characters and pass it to a int type
> hinted function -
On Thu, Mar 8, 2012 at 12:22 PM, adit adit wrote:
> Let's try to stick only to the internals blogs, ok? If any other php core
> devs have some blogs..
> I found also Sara Golemon's blog but is discontinued for some years
> now.
>
>
if by internals you only mean "blogs that are talking abo
Let's try to stick only to the internals blogs, ok? If any other php core
devs have some blogs..
I found also Sara Golemon's blog but is discontinued for some years now.
On Thu, Mar 8, 2012 at 1:09 PM, Peter Beverloo wrote:
> There is a Planet PHP which aggregates many blogs articles w
There is a Planet PHP which aggregates many blogs articles written by
contributors:
http://planet-php.net/
Peter
On Thu, Mar 8, 2012 at 09:58, adit adit wrote:
> Hi,
>
> Can you tell me which one of you guys has any blogs on which i can read
> about the php internals?
> I've already subscribed
2012/3/8 John Crenshaw :
> From: Arvids Godjuks [mailto:arvids.godj...@gmail.com]
>
>> > I like that. What should we do if this appears? As it's now - just
>> > throw an "Catchable fatal error" and let the script blow-up? I would
>> > go this far.
>>
>> I think "Catchable fatal error should" be fin
Hi,
Yea! I really need that too.
One thing I can provide is my own blog, but it's more stuff about bugs in
systems, ideas I come around and implementation-possibilities. Nothing
really internal.
http://www.simonsimcity.net/
Other interesting blogs (all in german):
http://www.phpgangsta.de/
http:
On Thu, Mar 08, 2012 at 11:06:56AM +0200, Arvids Godjuks wrote:
> > Type hints are meant to
> > filter input from external sources
>
> Correction, it should read like this:
> Type hints are _not_ meant to filter input from external sources
+1
What they will do is to catch where input from extern
oh, forgot to mention, i'm subscribed to that one also, is really good & in
english.
Any others?
On Thu, Mar 8, 2012 at 11:59 AM, Charlie Somerville <
char...@charliesomerville.com> wrote:
> Nikita's is pretty interesting: http://nikic.github.com/
>
> On Thursday, 8 March 2012 at 8:58 PM, adit ad
Hi,
Can you tell me which one of you guys has any blogs on which i can read
about the php internals?
I've already subscribed to laruence's , problem is google translate is
pretty bad at translating chinese
Thanks,
From: Arvids Godjuks [mailto:arvids.godj...@gmail.com]
> > I like that. What should we do if this appears? As it's now - just
> > throw an "Catchable fatal error" and let the script blow-up? I would
> > go this far.
>
> I think "Catchable fatal error should" be fine and users are familiar with
On Thu, Mar 8, 2012 at 10:03 AM, Arvids Godjuks wrote:
> Hi Simon!
>
> 2012/3/8 Simon Schick :
> > Hi Arvids,
> >
> > I pretty much like this idea as it's more strict. Let me say something
> > to the questions you pointed out here.
> >
> > 2012/3/7 Arvids Godjuks :
> >> I realize that with scalars
> Type hints are meant to
> filter input from external sources
Correction, it should read like this:
Type hints are _not_ meant to filter input from external sources
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Simon!
2012/3/8 Simon Schick :
> Hi Arvids,
>
> I pretty much like this idea as it's more strict. Let me say something
> to the questions you pointed out here.
>
> 2012/3/7 Arvids Godjuks :
>> I realize that with scalars it's not that straight forward, but
>> complicating things by adding an au
On Mon, 05 Mar 2012 17:52:52 +0100, Remi Collet wrote:
>
> Using a simple C program (linked against libmash)
>
> Hash: fdb9019a79c33a95677e2097abae91eb0de00b3054bb5c39
>
> So the result from php <= 5.3.10 seems the right one.
Sorry for the delay, but I already explained the issue in
the bug re
41 matches
Mail list logo
