On Tue, 2 Aug 2011, Hannes Landeholm wrote:
> (This announcement was sent twice since the last announcement was
> merged with the existing thread instead of starting a new thread.)
No it wasn't. There were no References or In-Reply-To headers. Anything
that merged it did it wrongly.
Derick
--
Hi.
Given the relatively simple code below, why can't I throw an exception
in __toString()?
asString();
}
catch(Exception $ex) {
echo $ex->getMessage();
}
try {
echo $failure;
}
catch(Exception $ex) {
echo $ex->getMessage();
}
?>
outputs ...
Failed in asString()
Fatal error: Method Alway
Hello,
On Tue, Aug 2, 2011 at 16:47, Richard Quadling wrote:
> Hi.
>
> Given the relatively simple code below, why can't I throw an exception
> in __toString()?
The (historic) reason is that the toString conversion occurs at
various places in the engine, and in some of them, throwing exceptions
Hannes Landeholm wrote:
I've been a PHP fan for years and endured the patchy OO implementation
and the limitations that has come with the language for the
simplicity. Unfortunately I don't have time to wait for years even if
many of you guys do. If I did I wouldn't have bothered writing the RFC
o
This would make perfect sense with constant strings and constant
length, when using variables this may lead to some magic bugs, which
would be normally reported as E_WARNING. Not sure if it's a good idea
:(
Jan Dolecek
juzna...@gmail.com
On Mon, Aug 1, 2011 at 7:40 AM, Laruence wrote:
> Hi eve
On 2 August 2011 16:09, Keloran wrote:
> i didnt think any of the magic functions could throw exceptions
All magic methods can throw exceptions except __toString.
There is some oddity with __set_state() (in terms of the pattern of
output is different).
http://pastebin.com/nGkP7kKf
outputs ...
On Tue, Aug 2, 2011 at 4:47 PM, Richard Quadling wrote:
> Hi.
>
> Given the relatively simple code below, why can't I throw an exception
> in __toString()?
>
> class AlwaysFails {
> public function asString() {
> throw new Exception('Failed in asString()');
> }
>
> public function __toStrin
I've talked to Etienne and he still believes we should vote on this so the
vote is still up. He just replied to quickly. If the vote fails the patch
can still be implemented in a PECL extension. There's no point canceling the
vote or the RFC - it's still valid and ongoing, and there is still time
I have a zval *obj holding an object of class B, which I then add to an
array member of another object of class A. Then I create a new instance
*obj2 of class B, to which I want to add a reference to *obj. How would
I best go about it?
So A works as a "pool" of B's, and B's may reference to ea
Hello,
On Tue, Aug 2, 2011 at 22:05, Flavius Aspra wrote:
> I have a zval *obj holding an object of class B, which I then add to an
> array member of another object of class A. Then I create a new instance
> *obj2 of class B, to which I want to add a reference to *obj. How would I
> best go about
Hello,
On Tue, Aug 2, 2011 at 11:06 AM, Hannes Landeholm wrote:
> I've talked to Etienne and he still believes we should vote on this so the
> vote is still up. He just replied to quickly. If the vote fails the patch
> can still be implemented in a PECL extension. There's no point canceling the
Hi!
On 8/2/11 7:51 AM, Etienne Kneuss wrote:
The (historic) reason is that the toString conversion occurs at
various places in the engine, and in some of them, throwing exceptions
caused trouble. It is not clear whether this limitation it still
required. In any case, it could almost certainly be
Adding a new feature to the latest version of PHP will not make it
available to users of shared hosting. Many of these are running on older
versions and it takes time for them to get updated to the latest.
- Frank
On 8/2/11 11:06 AM, Hannes Landeholm wrote:
I've talked to Etienne and he sti
Hannes Landeholm wrote:
Certain function in the application runs a MySQL procedure that updates a
> certain complex selection of products in the products database rendering the
> currently loaded products in memory obsolete since they might have been
> updated.
Then you are caching the wrong da
Hi!
On 8/1/11 3:30 PM, Hannes Landeholm wrote:
lists or write RFC's or learn C or jump trough endless hoops in a
process designed so that the core development team can ignore the
community more democratically. The users that just suck it up and
design their applications or frameworks poorly inst
On 2 August 2011 23:32, Chris Stockton wrote:
> I would like to make a couple points here, first I is that PECL is not
> a place for a extension to rot, that statement makes absolutely no
> sense to me. PDO I recall years ago getting from PECL, Http a
> extension I often use, was recently on this
On 08/02/2011 05:44 PM, Hannes Landeholm wrote:
I had a two week discussion period that was mostly silent and I felt
the consensus was generally in favor of the feature which is why I
started the vote.
@internals silence on new features can be interpreted both ways.
Looking at the general fe
Hello Stas,
On 3 August 2011 02:39, Stas Malyshev wrote:>
> I notice some tone of hostility here.
I'm not hostile. Perhaps a bit disappointed that the PECL objection
wasn't brought up earlier in the discussion period so It could have
been toughly discussed.
> /* snip */
> This is why we tend to
Tired...
> I don't agree with the concept of putting new feature in PECL itself...
should of course be:
>I don't disagree with the concept of putting new feature in PECL itself...
~Hannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.p
Hi!
On 8/2/11 6:25 PM, Hannes Landeholm wrote:
I'm referring to the fact that PHP has a major update once a year.
Looking at it from an agile perspective this is insanely slow. I think
you should use smaller iterations and release faster. The new Mozilla
release schedule is a good example.
Hav
On 08/02/2011 06:25 PM, Hannes Landeholm wrote:
> I have no problem compiling extensions and I also don't have any
> customers on share hosting. Although it wastes a bit more of my time
> I'm personally fine with PECL. I'm contributing to open source though
> so I'm concerned with the users that wo
21 matches
Mail list logo
