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
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
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
> 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
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
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
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
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, 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
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, 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
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
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
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
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 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!
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
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
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
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
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 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
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 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
> }
>
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 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
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 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
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 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 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
>
>
>
> 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
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
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
>
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
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!
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
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
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
39 matches
Mail list logo