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 report:
Hi Simon!
2012/3/8 Simon Schick simonsimc...@googlemail.com:
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 arvids.godj...@gmail.com:
I realize that with scalars it's not that straight
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
On Thu, Mar 8, 2012 at 10:03 AM, Arvids Godjuks arvids.godj...@gmail.comwrote:
Hi Simon!
2012/3/8 Simon Schick simonsimc...@googlemail.com:
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
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
such
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,
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 adit
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 external
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/
2012/3/8 John Crenshaw johncrens...@priacta.com:
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
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 miche...@gmail.com 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
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 pe...@lvp-media.com wrote:
There is a Planet PHP which aggregates
On Thu, Mar 8, 2012 at 12:22 PM, adit adit miche...@gmail.com 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
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 -
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
On Thu, 08 Mar 2012 13:38:32 +0100, Anthony Ferrara ircmax...@gmail.com
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.
2012/3/8 John Crenshaw johncrens...@priacta.com:
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
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
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
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 the delay, but I
On Thu, 08 Mar 2012 17:05:19 +0100, Michael Morris
dmgx.mich...@gmail.com 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
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?
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:
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
2012/3/8 Remi Collet r...@fedoraproject.org
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
On Thu, Mar 8, 2012 at 5:30 PM, Sebastian Bergmann sebast...@php.net 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,
--
2012/3/8 Sebastian Bergmann sebast...@php.net:
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/
--
2012/3/8 Sebastian Bergmann sebast...@php.net:
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/
--
On Thu, 08 Mar 2012 17:51:34 +0100, Michael Morris
dmgx.mich...@gmail.com 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
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 and
On 9 March 2012 00:11, Remi Collet r...@fedoraproject.org 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
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
On Thu, Mar 8, 2012 at 6:08 PM, John Crenshaw johncrens...@priacta.comwrote:
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
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):
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 ircmax...@gmail.com wrote:
Hey all,
As promised, I've created a
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 ircmax...@gmail.com wrote:
Hey all,
As promised, I've created a
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 ircmax...@gmail.com wrote:
Hey all,
As promised, I've created
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
On Fri, Mar 9, 2012 at 10:58 AM, Ilia Alshanetsky i...@prohost.org 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
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 3:58 AM, Ilia Alshanetsky i...@prohost.org 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
41 matches
Mail list logo
