On Fri, 2004-02-13 at 18:54, Sterling Hughes wrote:
[...]
> I get the concept, that's the reason Exception was added. But its meant
> to be a voluntary thing (I believe this has been discussed before btw),
> a standard class that gives users something to build upon, should they
> want to. I think
On Sat, 2004-02-14 at 11:38, Zeev Suraski wrote:
> >>My experience is a bit of the opposite, and the truth is somewhere in the
> >>middle I guess. But anyway, if you want to error out, why not just do
> >>that? Why go through the mess of coming up with an exception that will
> >>propagate thro
At 12:24 15/02/2004, Adam Bregenzer wrote:
On Sat, 2004-02-14 at 11:38, Zeev Suraski wrote:
> >>My experience is a bit of the opposite, and the truth is somewhere in
the
> >>middle I guess. But anyway, if you want to error out, why not just do
> >>that? Why go through the mess of coming up with
At 12:04 15/02/2004, Timm Friebe wrote:
I agree with Sterling. What if I have some really methods in my base
class that I rely on being existant in each and every subclass of it,
including Exception (or any other name I thought of to work around
"Exception" being built-in)?
Couldn't quite understan
On 15 Feb 2004 at 13:08, Zeev Suraski wrote:
> At 12:04 15/02/2004, Timm Friebe wrote:
> >I agree with Sterling. What if I have some really methods in my base
> >class that I rely on being existant in each and every subclass of it,
> >including Exception (or any other name I thought of to work
ar
On Sun, 2004-02-15 at 12:08, Zeev Suraski wrote:
> At 12:04 15/02/2004, Timm Friebe wrote:
> >I agree with Sterling. What if I have some really methods in my base
> >class that I rely on being existant in each and every subclass of it,
> >including Exception (or any other name I thought of to work
Hi,
On 8 Feb 2004, at 21:26, Rasmus Lerdorf wrote:
Perhaps the real answer here is to turn on input filtering by default
so
we defeat XSS once and for all across the board.
seems like nobody is interested. I'd like to see some sort
of discussion on this. How would an actual implementation
would or
Hi Timm,
On Sun, 15 Feb 2004 12:53:21 +0100, Timm Friebe wrote:
> As of B4, this is no longer possible. That's why i was agreeing to
> Sterling in saying it should be optional to use the built-in exception
> class. If there was a requirement to implement an interface (call it
> Throwable,
Hello Adam,
Sunday, February 15, 2004, 12:06:25 PM, Zeev Suraski wrote:
> At 12:24 15/02/2004, Adam Bregenzer wrote:
>>On Sat, 2004-02-14 at 11:38, Zeev Suraski wrote:
>> > >>My experience is a bit of the opposite, and the truth is somewhere in
>> the
>> > >>middle I guess. But anyway, if you wa
Hi Ard,
On Fri, 13 Feb 2004 18:45:51 +0100, Ard Biesheuvel wrote:
> 'Finally' is used for code that is executed anyway, whether an exception
> has occurred or not. This is different from 'catch (...)' because the
> catch clause is not executed if the try block exits with no eceptions.
>
> Like
>
I understand mostly everything you say except for why there's any
motivation to introduce more headaches in the form of a new Throwable
interface, forcing people to become acquainted with interfaces before
they can throw an exception. Under the assumption that we want to
Not true, because the
On Sun, Feb 15, 2004 at 04:12:08PM +0100, Marcus Boerger wrote:
> Even if it were not the best solution it is still the solution that fits PHP
> best and which is easiest to the developers. And as i said a while back the
> current exception class allows several things a user implementation cannot
>
Ard, if the Exception class is not the base class of all exceptions(catch
all), it's very difficult to emulate "finally"(You must know every
exception that may be thrown inside the try block, and sometimes you
don't).
Of course, I was just stating that 'finally' != 'catch (...)', while
some of the
Hi Marcus,
On Sun, 15 Feb 2004 16:12:08 +0100, Marcus Boerger wrote:
> Even if it were not the best solution it is still the solution that fits
> PHP best and which is easiest to the developers. And as i said a while
> back the current exception class allows several things a user
> implementation
Hello Stefan,
Sunday, February 15, 2004, 4:32:21 PM, you wrote:
> On Sun, Feb 15, 2004 at 04:12:08PM +0100, Marcus Boerger wrote:
>> Even if it were not the best solution it is still the solution that fits PHP
>> best and which is easiest to the developers. And as i said a while back the
>> curre
Hello Cristiano,
Sunday, February 15, 2004, 4:37:37 PM, you wrote:
> Hi Marcus,
> On Sun, 15 Feb 2004 16:12:08 +0100, Marcus Boerger wrote:
>> Even if it were not the best solution it is still the solution that fits
>> PHP best and which is easiest to the developers. And as i said a while
>> bac
On Sun, 15 Feb 2004, Jan Lehnardt wrote:
> On 8 Feb 2004, at 21:26, Rasmus Lerdorf wrote:
> > Perhaps the real answer here is to turn on input filtering by default
> > so
> > we defeat XSS once and for all across the board.
>
> seems like nobody is interested. I'd like to see some sort
> of discu
On Sun, 2004-02-15 at 16:09, Cristiano Duarte wrote:
> Hi Timm,
[...]
> IMHO, as you said, using an interface and letting the built-in class
> implement it is the best approach. But only instances of classes wich
> implement this interface should be throw or caught(language enforcement).
> With thi
On Sat, 14 Feb 2004, Derick Rethans wrote:
>On Sat, 14 Feb 2004, Jani Taskinen wrote:
>
>> On Sat, 14 Feb 2004, Derick Rethans wrote:
>>
>> >On Sat, 14 Feb 2004, Eric Colinet wrote:
>> >
>> >> I think you should realy take a look at that:
>> >> http://marc.theaimsgroup.com/?l=php-dev&m=10757147122
This is either bug in zend_fetch_list_dtor_id() as said in the
bug report or misuse of [zend_]register_list_destructors().
So which one is it? Is zend_register_list_destructors() deprecated in
favor of zend_register_list_destructors_ex() or what??
FYI: register_list_des
On Sun, 8 Feb 2004, Sascha Schumann wrote:
>Is "on" supposed to produce garbage (apparently
>Content-Encoding is simply missing), while 1 is the one true
>setting? I always thought they were equivalent in the
>context of a boolean flag.
>
># works
>php_admin_value zlib.out
It appears that cloning is broken, since a modification to the clone
modifies the original. For my __clone method implementation, I allow
all of the variables to be set by default except for one. But this
problem persists even when I don't modify that one variable.
--
PHP Internals - PHP Runtim
I forgot to mention: I am use b4
On 15 Feb 2004, at 5:45 PM, Herr Witten wrote:
It appears that cloning is broken, since a modification to the clone
modifies the original. For my __clone method implementation, I allow
all of the variables to be set by default except for one. But this
problem p
Hello,
most probably that property is a reference in which case the result is
correct.
Sunday, February 15, 2004, 11:45:56 PM, you wrote:
> It appears that cloning is broken, since a modification to the clone
> modifies the original. For my __clone method implementation, I allow
> all of the v
It appears that only one of the variables, an array, is being shared
across these multiple objects, but other array variables are not.
Moreover, When I make a clone and then set the clone to null, all
clones made thereafter are correct.
$clone = clone $object;
$clone = null;
Also, I can't repli
More specifically,
This causes a change in $object:
$clone = clone $object;
$clone->troublesomeVariable = array();
But this doesn't:
$clone = clone $cell;
$clone = null;
$clone->_subElements = array();
On 15 Feb 2004, at 7:35 PM, Herr Witten wrote:
It appears that only one of the variables, an
That should be clone $object for the example.
On 15 Feb 2004, at 7:39 PM, Herr Witten wrote:
$clone = clone $cell;
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello,
first as i said do the following to verify:
[EMAIL PROTECTED] /usr/src/php5 $ php -r '$a=array(1,2);class t{public $a;function
f(){$this->a=&$GLOBALS["a"];}}$o1=new t;$o1->f();var_dump($o1);$o2=clone
$o1;$o1->a=2;var_dump($o2);var_dump($o1);'
make: `sapi/cli/php' is up to date.
object(t)#
first as i said do the following to verify:
It's a nice example, but it doesn't apply. I don't make a reference.
second read the docs and question such things on [EMAIL PROTECTED]
I did. This problem seemed to be internal, and it still does.
--
PHP Internals - PHP Runtime Development Mailing List
Hello,
Monday, February 16, 2004, 1:54:36 AM, you wrote:
>> first as i said do the following to verify:
> It's a nice example, but it doesn't apply. I don't make a reference.
>> second read the docs and question such things on [EMAIL PROTECTED]
> I did. This problem seemed to be internal, and
Here, I have reproduced the problem:
class A
{
var $a = array();
public function makeAReference()
{
$array = $this->getA();
}
public function &getA()
{
return $this->a;
}
}
$A = new A;
$A->a = array(1);
$A->makeAReference();
$clone = clone $A;
$clone->a
This too:
class A
{
var $a = array();
public function &getA()
{
return $this->a;
}
}
$A = new A;
$A->a = array(1);
$array = &$A->getA();
$clone = clone $A;
$clone->a = array();
print_r($A);
On 15 Feb 2004, at 9:14 PM, Herr Witten wrote:
Here, I have reproduced the problem
Hi -
Sebastian Bergmann wrote:
Andi Gutmans wrote:
Zeev is planning on fixing this.
Cool.
Interfaces should be allowed to extend other interfaces but not
to implement them.
interface Bar extends Foo {}
works already (at least last time I checked). What I need (and meant) is
int
Hans Lellelid wrote:
> I thought this was going to be fixed for beta4/RC1, but still seems
> not to be.
Works for me:
Greetings,
Sebastian
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Das Buch zu PHP 5: http://professionelle-softwar
I'm getting a segfault at the end of (successful) script execution.
Appears to be an issue in the shutdown sequence; I'm unsure how to
report this bug, since providing duplicating code is not possible.
The segfault is happening at the end of a Phing (http://phing.info)
build process, which invo
Sebastian Bergmann wrote:
Hans Lellelid wrote:
I thought this was going to be fixed for beta4/RC1, but still seems
not to be.
Works for me:
Apologies! -- yes, it does work. I was still doing the old "Foo
implements Foo, Bar" which used to work (but never should have).
Thanks-
Hans
--
PHP I
I have a need in a current application to extend interfaces and possibly
re-define (change signature) some of the inherited methods in the child
interface.
e.g.
interface Foo {
public function __construct(MyCls $var);
public function myFunction();
}
interface Bar extends Foo {
37 matches
Mail list logo
