AZ>> Any objections to modifying zend_lookup_class() to support fully
AZ>> qualified class names? Meaning, if it's passed 'A::B' it will lookup
AZ>> class B in namespace A? This change would take a care of several
AZ>> places in the code where class name can be passed.
Could you point out which pl
Hello,
"Ilia Alshanetsky" <[EMAIL PROTECTED]>
> Modified files:
> /php4/ext/gd/libgd gd.c gd.h gd_gd.c gd_gd2.c gd_io.h gd_jpeg.c
> gd_png.c gd_topal.c gdcache.c gdcache.h gdft.c
> gdkanji.c
> Log:
> Syncronized bunbled GD library with gd 2.0.
At 21:54 05.04.2003, Marcus Börger wrote:
For all interested, i used this for SPL and it works fine.
As i was asked for the SPL url:
http://marcus-boerger.de/php/ext/spl/
marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
At 22:27 02.04.2003, Andrei Zmievski wrote:
andrei Wed Apr 2 15:27:45 2003 EDT
Modified files:
/ZendEngine2zend_API.c zend_API.h
Log:
- Add zend_register_internal_namespace() API function.
- Add zend_register_internal_class_in_ns() API function.
For all interested, i
At 20:11 05.04.2003, Rasmus Lerdorf wrote:
> Jani, IMO --enable-all is a good thing but it shouldn't apply to --with
> extensions. So perhaps we should have an undocumented --with-all
> and make --enable-all what it is supposed to.
--with-all is rather unrealistic, isn't it? Some of the --with fla
> Jani, IMO --enable-all is a good thing but it shouldn't apply to --with
> extensions. So perhaps we should have an undocumented --with-all
> and make --enable-all what it is supposed to.
--with-all is rather unrealistic, isn't it? Some of the --with flags are
mutually exclusive as well so you c
At 19:48 05.04.2003, Jani Taskinen wrote:
On Sat, 5 Apr 2003, Marcus Börger wrote:
>I just noticed the fact that --enable-all also works for all --with-xyz by
>being mailed about it. IMHO there should be an --with-all. This because
>we have a clear difference between --enable-xy and --with-xy. Thi
On Sat, 5 Apr 2003, Marcus Börger wrote:
>I just noticed the fact that --enable-all also works for all --with-xyz by
>being mailed about it. IMHO there should be an --with-all. This because
>we have a clear difference between --enable-xy and --with-xy. This
>difference should hold for --enable-all
> Again: This point of view seems to clash with the vision that Stig and
> some others over at pear-dev had about PECL. Anyways, I don't really
> care about PECL much at the moment and thus won't invest to much energy
> in this discussion ;-).
The vision is different for everyone it seems. Last I
At 17:28 05.04.2003, Peter Neuman wrote:
Hello,
"Marcus Börger" <[EMAIL PROTECTED]>:
> I just noticed the fact that --enable-all also works for all --with-xyz by
> being mailed about it. IMHO there should be an --with-all. This because
> we have a clear difference between --enable-xy and --with-x
Hello,
"Marcus Börger" <[EMAIL PROTECTED]>:
> I just noticed the fact that --enable-all also works for all --with-xyz by
> being mailed about it. IMHO there should be an --with-all. This because
> we have a clear difference between --enable-xy and --with-xy. This
> difference should hold for --en
> At 13:51 05.04.2003, Marcus Börger wrote:
> >At 19:01 04.04.2003, Sterling Hughes wrote:
> >>sterlingFri Apr 4 12:01:10 2003 EDT
> >>
> >> Modified files:
> >>/php4 CODING_STANDARDS
> >> Log:
> >> both these entries are bad, and were never agreed upon.
> >> assert()
I just noticed the fact that --enable-all also works for all --with-xyz by
being mailed about it. IMHO there should be an --with-all. This because
we have a clear difference between --enable-xy and --with-xy. This
difference should hold for --enable-all, too.
regards
marcus
--
PHP Internals - PHP R
At 03:29 PM 4/5/2003 +0200, Marcus Börger wrote:
At 14:52 05.04.2003, Andi Gutmans wrote:
At 01:12 PM 4/5/2003 +0200, Marcus Börger wrote:
At 18:07 04.04.2003, Andrei Zmievski wrote:
On Fri, 04 Apr 2003, Derick Rethans wrote:
> > Well its a BC nightmare, and I don't really see any big advantage.
>
At 14:52 05.04.2003, Andi Gutmans wrote:
At 01:12 PM 4/5/2003 +0200, Marcus Börger wrote:
At 18:07 04.04.2003, Andrei Zmievski wrote:
On Fri, 04 Apr 2003, Derick Rethans wrote:
> > Well its a BC nightmare, and I don't really see any big advantage.
>
> Agreed, breaking BC for this sounds like a bad
At 01:12 PM 4/5/2003 +0200, Marcus Börger wrote:
At 18:07 04.04.2003, Andrei Zmievski wrote:
On Fri, 04 Apr 2003, Derick Rethans wrote:
> > Well its a BC nightmare, and I don't really see any big advantage.
>
> Agreed, breaking BC for this sounds like a bad idea to me.
sometimes I just hate BC..
I'm not sure if it's a good idea to change it or if we'd want a new
function because zend_lookup_class() is used in the core executor and this
would just slow it down. Can you give me an example of where you'd want
this to work?
Andi
At 11:20 AM 4/4/2003 -0500, Andrei Zmievski wrote:
Any objec
At 02:54 PM 4/4/2003 +0200, Sebastian Bergmann wrote:
Sascha Schumann wrote:
> Well, indent(1) will probably achieve the same result with
> the right options..
Then why not agree on a correct set of indent options, apply them to
the whole tree at once and maybe integrate indent into our CVS sys
At 10:36 PM 4/2/2003 -0800, Rasmus Lerdorf wrote:
On Wed, 2 Apr 2003, Andi Gutmans wrote:
> I'm not completely sure but from first glance at exif it is *completely*
> broken everywhere.
> You're not supposed to use zval_dtor() on parameters you get via
> zend_get_parameters_ex(). They are read-onl
At 13:51 05.04.2003, Marcus Börger wrote:
At 19:01 04.04.2003, Sterling Hughes wrote:
sterlingFri Apr 4 12:01:10 2003 EDT
Modified files:
/php4 CODING_STANDARDS
Log:
both these entries are bad, and were never agreed upon.
assert() usage is a controversial concept
On Sat, 5 Apr 2003, Sascha Schumann wrote:
> sas Sat Apr 5 06:22:15 2003 EDT
>
> Modified files:
> /php4/ext/session php_session.h session.c
> Log:
> dividend -> divisor
>
> Submitted by: Jesus M. Castagnetto <[EMAIL PROTECTED]>
But it still breaks BC lik
At 18:07 04.04.2003, Andrei Zmievski wrote:
On Fri, 04 Apr 2003, Derick Rethans wrote:
> > Well its a BC nightmare, and I don't really see any big advantage.
>
> Agreed, breaking BC for this sounds like a bad idea to me.
sometimes I just hate BC..
Sometimes as in this case BC means sticking to
Derick Rethans wrote:
> I'd go for a notice instead, just like the other things like using an
> uninitialized variable.
That's what I meant, of course.
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Did I help you? Consider a gift: http://w
23 matches
Mail list logo
