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 an
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 through God
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 an
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 understand
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
around
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 around
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, for
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
try
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
current
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
back the
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 discussion on
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 this
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:
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
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
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
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
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
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)#1 (1)
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
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 it
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
Hans Lellelid wrote:
I thought this was going to be fixed for beta4/RC1, but still seems
not to be.
Works for me:
?php
interface Foo {
public function doFoo();
}
interface Bar {
public function doBar();
}
interface Barbara extends Foo, Bar {}
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
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
33 matches
Mail list logo
