On 05/19/2010 14:43, Johannes Schlüter wrote:
Hi,
On Wed, 2010-05-19 at 13:03 +0200, fqqdk wrote:
2010/5/19 Tjerk Anne Meestersdatib...@php.net
I wrote a small article that gives an idea of the speed differences:
http://shwup.blogspot.com/2010/04/about-constants.html
Unfortunately this
On Wed, 2010-06-09 at 10:51 +0200, Frederic Hardy wrote:
See zval_update_constant_ex in zend_API.c as a starting point. While
such an approach would also require some parser work and some clever
idea where/how to store the expression to be evaluated etc.
So, it's possible ?
Very good
Hi all:
On Wed, Jun 9, 2010 at 1:59 AM, Daniel Convissor
dani...@analysisandsolutions.com wrote:
Hi Lukas:
On Fri, Jun 04, 2010 at 08:28:12AM +0200, Lukas Kahwe Smith wrote:
Same deal as E_NOTICE. Either you care about them or you dont.
Exactly. The type hinting situation is unique.
On 9 June 2010 00:59, Daniel Convissor dani...@analysisandsolutions.com wrote:
Hi Lukas:
On Fri, Jun 04, 2010 at 08:28:12AM +0200, Lukas Kahwe Smith wrote:
Same deal as E_NOTICE. Either you care about them or you dont.
Exactly. The type hinting situation is unique. It is something that
On 09.06.2010, at 12:01, André Rømcke wrote:
Example:
function fetchById( int $id, bool $asObject = true )
If weak type hints are accepted, type hints would be useless in this case as
consumer can do something strange as fetchById( true, 'foo' ) (Obviously I'm
not saying anyone would do
Hi Lukas!
On Wed, Jun 9, 2010 at 12:08 PM, Lukas Kahwe Smith m...@pooteeweet.orgwrote:
On 09.06.2010, at 12:01, André Rømcke wrote:
Example:
function fetchById( int $id, bool $asObject = true )
If weak type hints are accepted, type hints would be useless in this case
as
consumer
On Wed, Jun 9, 2010 at 12:08 PM, Lukas Kahwe Smith m...@pooteeweet.orgwrote:
On 09.06.2010, at 12:01, André Rømcke wrote:
Example:
function fetchById( int $id, bool $asObject = true )
If weak type hints are accepted, type hints would be useless in this case
as
consumer can do
- trigger_error OR exceptions? (we said, that exceptions shouldn't be
allowed inside the core, so maybe this can be only impelemted through
spl)
I think the exception discussion should be omitted. There exists some
other RFCs to fix this issue.
http://wiki.php.net/rfc/enhanced_error_handling
At 02:59 09/06/2010, Daniel Convissor wrote:
Hi Lukas:
On Fri, Jun 04, 2010 at 08:28:12AM +0200, Lukas Kahwe Smith wrote:
Same deal as E_NOTICE. Either you care about them or you dont.
Exactly. The type hinting situation is unique. It is something that
applications will frequently want to
On Sat, Jun 5, 2010 at 11:05 PM, Eric Stewart ericleestew...@gmail.comwrote:
Wrote up and attempted to commit a news announcement for TestFest 2010,
only to find out I don't have karma for that section of the repository. I've
attached the entry XML file if someone would be kind enough to
On Wed, Jun 9, 2010 at 4:17 PM, Zeev Suraski z...@zend.com wrote:
At 02:59 09/06/2010, Daniel Convissor wrote:
Hi Lukas:
On Fri, Jun 04, 2010 at 08:28:12AM +0200, Lukas Kahwe Smith wrote:
Same deal as E_NOTICE. Either you care about them or you dont.
Exactly. The type hinting
On 05.06.2010, at 22:47, Stefan Marr wrote:
Hi:
Was just thinking about some details of the traits implementation.
From my perspective, static variables in methods should work like the method
would have been actually implemented in the class using the traits. Thus,
static variables
-Original Message-
From: Zeev Suraski [mailto:z...@zend.com]
Sent: 09 June 2010 15:17
To: Daniel Convissor
Cc: PHP Internals List
Subject: Re: [PHP-DEV] Type hinting
At 02:59 09/06/2010, Daniel Convissor wrote:
Hi Lukas:
On Fri, Jun 04, 2010 at 08:28:12AM +0200, Lukas
Hi!
Let's me take the name __create() for this example :
We already have __construct for creating objects of class Foo, and if
those are objects of another class, you can always have a static factory.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
On 2010-06-09 16:06:37 +0200, Ferenc Kovacs said:
In fact the uniq problem i see, is could be a name conflict like :
function Foo() {
// ...
}
class Foo() {
public __create() {
// ...
}
}
Foo(); // Instanciate the class or call the function ?
And I think that this is a much higher
At 19:55 09/06/2010, Jared Williams wrote:
Is E_TYPE good enough? If it follows the other E_*, I'd suggest it's
not.
Yes, same error mechanism.
Just having a single string error message describing the error, and
having to unmangle the detailed information* from that doesn't seem
that great.
At 17:54 09/06/2010, Ferenc Kovacs wrote:
If we introduce the E_TYPE what will be the new default/suggested error level?
If it won't be enabled by default, then maybe we could introduce
this in the whole language.
I mean, if you implicitly convert '123asd' to integer, you will
trigger this
for example:
$foo = 0;
$foo += (int)'123abc'; // no error
$foo += '123abc'; // E_TYPE
Exactly. And to make sure we're on the same page:
$foo += '123'; // no error
+1
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Zeev:
On Wed, Jun 09, 2010 at 05:17:13PM +0300, Zeev Suraski wrote:
I think having E_TYPE (or whatever), a non-fatal notice that can be
either ignored or handled separately from everything else makes sense. I
think we may actually want to introduce it at the most basic levels of
PHP,
19 matches
Mail list logo
