On Thu, Apr 28, 2011 at 4:10 AM, Ben Schmidt
mail_ben_schm...@yahoo.com.auwrote:
Hi!
I realise that at least for now, PHP is sticking with SVN. No problems.
However...I find it much easier to work in Mercurial to put together
patches, find bugs, etc.. And in fact, I find SVN really
dukeofgaming wrote:
http://programmers.stackexchange.com/questions/35074/im-a-subversion-geek-why-i-should-consider-or-not-consider-mercurial-or-git-or/35080#35080
So, I don't want to make debate here of wether centralized is better than
distributed (because the point is moot), but I think its
Hi!
http://wiki.php.net/rfc/returntypehint
for the upcoming 5.4 release, I think it would be extremely useful, even
without the scalar stuff.
Personally, I see even less point in having strict return typing (please
stop using hint terminology, it confuses the whole matter, it's not
hint
Am 28.04.2011 10:23, schrieb Stas Malyshev:
But why would I want to see these errors?
How they would make anything easier or better?
to find problems before your users?
i do not know what you want, but i want with
error_reporting = E_ALL | E_STRICT get noticed if
something possible is
Hi!
to find problems before your users?
Sorry, this doesn't say much. It's a generic, of course we agree it's
good to find bugs sooner rather than later. The question is why would
that specific thing that is being proposed help - in which specific way?
the second one will produce an
On Thu, Apr 28, 2011 at 10:23 AM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
http://wiki.php.net/rfc/returntypehint
for the upcoming 5.4 release, I think it would be extremely useful, even
without the scalar stuff.
Personally, I see even less point in having strict return typing
All right ;-)
Johannes: Thanks for details about lighhtpd's internals.
Julien.P
2011/4/27 Johannes Schlüter johan...@schlueters.de
On Wed, 2011-04-27 at 15:36 +0200, Julien Pauli wrote:
I'm +1 with that list.
I'd like to have some time to work on a lighttpd sapi if possible
(haven't
The RFC doesn't explain it either beyond here how you can have some nice
errors.
But why would I want to see these errors? How they would make anything
easier or better?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
maybe we should
On Thu, Apr 28, 2011 at 01:35:00AM -0700, Stas Malyshev wrote:
Hi!
to find problems before your users?
Sorry, this doesn't say much. It's a generic, of course we agree it's
good to find bugs sooner rather than later. The question is why would
that specific thing that is being proposed
On Thu, Apr 28, 2011 at 10:39:55AM +0200, Ferenc Kovacs wrote:
do you aware that without the scalar support, the return type hinting would
behave just as strict as the argument type hinting is currently.
http://php.net/manual/en/language.oop5.typehinting.php
so maybe type hinting wasn't a
On 04/28/2011 01:58 AM, Alain Williams wrote:
On Thu, Apr 28, 2011 at 01:35:00AM -0700, Stas Malyshev wrote:
Hi!
to find problems before your users?
Sorry, this doesn't say much. It's a generic, of course we agree it's
good to find bugs sooner rather than later. The question is why would
On Thu, Apr 28, 2011 at 02:43:36AM -0700, Rasmus Lerdorf wrote:
function array foo() { }
$ret = foo();
foreach($ret as $val)
I don't see this being useful at all. All you are doing is duplicating a
runtime warning. We can't possibly know at
Hi,
In function zend_hash_init() when allocate no persistent memory (if flag
persistent is 0) for arBuckets element of struct HashTable and virtual
memory is over, the function always returns SUCCESS
Code:
if (persistent) {
tmp = (Bucket **) calloc(ht-nTableSize, sizeof(Bucket *));
if
On 04/28/2011 02:53 PM, Anton Dobkin wrote:
// No checking on return value?
Yes, it doesn't check for NULL.
See ecalloc() sources in Zend/zend_alloc.c around line 2434 to see why.
--
Wbr,
Antony Dovgal
---
http://pinba.org - realtime statistics for PHP
--
PHP Internals - PHP Runtime
Hey All,
I'm really interested on this topic.
What would be the result of this?
function Foo foo($something) {
if ( $something ) {
return new Foo;
}
// no return implies return null
}
How do you force to return a Type with null allowed?
Martin Scotta
On Thu, Apr 28,
On Thu, Apr 28, 2011 at 10:30:43AM -0300, Martin Scotta wrote:
Hey All,
I'm really interested on this topic.
What would be the result of this?
function Foo foo($something) {
if ( $something ) {
return new Foo;
}
// no return implies return null
}
How do you
FWIW, I don't see much point in this either, as far as error reporting is
concerned. I think type checking for parameters can provide cheap and useful
validation, as parameters passed in are outside the function's control. But return
values? They are within the function's control, and in most
On Fri, Apr 29, 2011 at 01:58:02AM +1000, Ben Schmidt wrote:
If PHP were compiled, not interpreted, i.e. less dynamic, there could be
some benefits, as compile-time optimisations could perhaps be built in, and
validations skipped if they were provably unnecessary. But that's not going
to
On 29/04/11 2:10 AM, Alain Williams wrote:
On Fri, Apr 29, 2011 at 01:58:02AM +1000, Ben Schmidt wrote:
If PHP were compiled, not interpreted, i.e. less dynamic, there could be
some benefits, as compile-time optimisations could perhaps be built in, and
validations skipped if they were provably
On Fri, Apr 29, 2011 at 02:38:31AM +1000, Ben Schmidt wrote:
I also see the value of such type checking for such a use case, obviously.
I guess there's a reason for it after all.
I'd still like to see something neat to handle more than just named
classes, though, e.g. scalars, and things
Martin Scotta
On Thu, Apr 28, 2011 at 12:58 PM, Ben Schmidt mail_ben_schm...@yahoo.com.au
wrote:
FWIW, I don't see much point in this either, as far as error reporting is
concerned. I think type checking for parameters can provide cheap and useful
validation, as parameters passed in are
Hi!
There will also be advantages for HipHop which can afford to spend the time to
do static analysis of code -- I know that HipHop is not your baby
but you now need to recognise that there is more than one PHP implementation
and features that may not had much advantage with Zend may be useful
On 04/27/2011 08:18 PM, 陈磊 wrote:
The bug url:
http://pecl.php.net/bugs/bug.php?id=22673
I would also suggest mailing apc-dev @ lists.php.net (even though there
is likely to be a big overlap in readership with internals@).
Chris
BRs,
Chen Lei
于 2011-4-27 18:34, Pierre Joye 写道:
hi,
Here's my issue:
We're borrowing a feature from strongly typed languages and forcing it on a
loosely typed language. I'm fine with this, if we're true to the concept.
In a regular language, if you type something to return an object of type Foo,
you might still get back null, and appropriately
On Thu, Apr 28, 2011 at 7:45 PM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
I see many advantages of the introduction of return type hinting.
- you can guarantee that your methods returns only what is explicitly
stated (or else it blows up, the same as for arguments)
You can't,
Martin Scotta
On Thu, Apr 28, 2011 at 2:51 PM, Matt Wilson sha...@gmail.com wrote:
Here's my issue:
We're borrowing a feature from strongly typed languages and forcing it on a
loosely typed language. I'm fine with this, if we're true to the concept.
In a regular language, if you type
Right, that's what null means. The difference in php is only in implementation
-- you actually just made my point :)
The only reason to have explicit null hints is if you get hung up on the whole
issue of how php actually implements NULL. The concept is non value, distinct
from empty. The
On Thu, Apr 28, 2011 at 10:45:34AM -0700, Stas Malyshev wrote:
Hi!
I see many advantages of the introduction of return type hinting.
- you can guarantee that your methods returns only what is explicitly
stated (or else it blows up, the same as for arguments)
You can't, because function
Hi!
it's the same as for the current argument type hinting.
you can access that information via Reflection
http://hu2.php.net/manual/en/reflectionparameter.getclass.php
Really? That's how you write your code - do a reflection check before
every call? Nobody does that.
why did we added ppp
On Thu, 2011-04-28 at 20:04 +0200, Ferenc Kovacs wrote:
Why I need being saved from documenting my code properly? Anyway, the
function code defines the behavior, declaration of return type just ensures
function would fail in runtime if your code tries to return unexpected data
- but how is
Martin Scotta
2011/4/28 Johannes Schlüter johan...@schlueters.de
On Thu, 2011-04-28 at 20:04 +0200, Ferenc Kovacs wrote:
Why I need being saved from documenting my code properly? Anyway, the
function code defines the behavior, declaration of return type just
ensures
function would
On Thu, Apr 28, 2011 at 8:49 PM, Stas Malyshev smalys...@sugarcrm.com
wrote:
Hi!
it's the same as for the current argument type hinting.
you can access that information via Reflection
http://hu2.php.net/manual/en/reflectionparameter.getclass.php
Really? That's how you write your code -
2011/4/28 Martin Scotta martinsco...@gmail.com:
* snip *
IMHO I would not trust on any return value, as PHP did not ensure anything
about them.
Even more, I do not write code that depend on return values, I prefer to
use input/output parameters,
I cannot help but wonder why PHP is your
Hi,
last week I wrote a bug report:
http://bugs.php.net/bug.php?id=54570
Maybe someone can look into it, because no modifications were made since
reporting. I am interested if it's a bug or If I should work around.
Greetings
Christian
--
PHP Internals - PHP Runtime Development Mailing List
To
That patch is not a good idea.
Assume you have this situation:
foo xmlns=urn:lol
x:bar xmlns:x=urn:hai
/x:bar
/foo
Adding a child baz to bar and have it default to no namespace
Actually, my patch wouldn't change the default action of addChild(). It would
still inherit the
While I think this would make SimpleXML more stupid, not less, as it seems
braindead to me to allow users to create documents ambiguously and/or which
essentially violate the XML namespace spec, I think the way to do this would be to
define a magic constant and use that. E.g.
const
Hi!
I will accept that sometimes it must always be done run time, eg:
$funcName($arg)
but that still allows most calls at compile time.
This is not the issue. This is the issue: $foo-bar($arg).
There's no way to resolve it in compile time, whatever that means,
without having a type on
37 matches
Mail list logo
