On Thu, Apr 28, 2011 at 4:10 AM, Ben Schmidt
wrote:
> 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 awkward--I was
> on the verge of
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 n
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 unc
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 error
On Thu, Apr 28, 2011 at 10:23 AM, Stas Malyshev wrote:
> 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
>
All right ;-)
Johannes: Thanks for details about lighhtpd's internals.
Julien.P
2011/4/27 Johannes Schlüter
> 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 seen lighttpd A
>
>
>
> 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
>
ma
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 pro
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
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
tha
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 Developme
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
> }
>
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 fu
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
> t
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 t
Martin Scotta
On Thu, Apr 28, 2011 at 12:58 PM, Ben Schmidt 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 outside the function's control
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 e
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 resolution happens in runtime, so the only
point you know what the fu
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 写道:
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 n
On Thu, Apr 28, 2011 at 7:45 PM, 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 functio
Martin Scotta
On Thu, Apr 28, 2011 at 2:51 PM, Matt Wilson 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 something to r
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 fu
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
> > - b
Martin Scotta
2011/4/28 Johannes Schlüter
> 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 run
On Thu, Apr 28, 2011 at 8:49 PM, Stas Malyshev
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 - do a reflec
2011/4/28 Martin Scotta :
* 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 language of choice. I m
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:
>
>
>
>
>
>
> 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 namespace qualification of the parent
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 SIMPLEXML_D
Hi!
yeah, but usually you return null/false in case of error when you write
procedural code.
Nope. I use it all the time when writing OO code and when "nothing" or
"no object" or "can't do this" is a valid answer for a function to return.
but since we wouldn't support the return typehint f
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
39 matches
Mail list logo
