Sure. It works fine with MSVC 6.0SP5.
Dmitry.
> -Original Message-
> From: Andrei Zmievski [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 19, 2006 1:29 AM
> To: Marcus Boerger
> Cc: Dmitry Stogov; Andi Gutmans; PHP Internals
> Subject: Re: [PHP-DEV] Changing arg type for 't' and 'T' s
I guess Andi already did it.
-Andrei
On Jul 18, 2006, at 11:33 PM, Dmitry Stogov wrote:
Do you mean create new file Zend/REDME.ZEND_MM or extend some
existing one?
Dmitry.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I agree.
I already use "zstr*" instead of (void**) in ext/soap code.
Dmitry.
> -Original Message-
> From: Andrei Zmievski [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 18, 2006 9:35 PM
> To: Andi Gutmans
> Cc: Dmitry Stogov; PHP Internals
> Subject: Changing arg type for 't' and 'T' s
Do you mean create new file Zend/REDME.ZEND_MM or extend some existing one?
Dmitry.
> -Original Message-
> From: Andrei Zmievski [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 18, 2006 9:13 PM
> To: Dmitry Stogov
> Cc: php-cvs@lists.php.net; internals@lists.php.net
> Subject: Re: [PHP-C
On 18.07.2006 22:59, Frank M. Kromann wrote:
Hello Everyone,
With the current version of CVS PHP_5_2 branch I get this compiler
warning:
c:\php\php5_2\zend\zend.c(565) : warning C4700: local variable 'tsrm_ls'
used without having been initialized
Fixed, thanks for the heads-up.
--
Wbr,
Anto
Steph Fox wrote:
I already agreed with Pierre over this, and offered to support him in
giving PEAR support for upgrading. So long as it goes in from the start
of 5_3 branch, why not? (Like it should've done at the start of 5_2
already.) I think it's worth holding out for a few more months to g
Rasmus Lerdorf wrote:
I can see Andrei's argument for the iterator stuff where you do actually
have to type it often, but his identifiers are already unlikely to clash
and we could probably make an exception there.
Well then we need to document this!
In my proposal I also noted:
Iterators an
Marcus Boerger wrote:
All that nonsense above said. I just would like to see that we agree on
having an official todo thing like lukas' site. Actually we should do
that on php.net somewhere and have a selected group get cvs access right
to that and have changes mailed to internals@ so that peopl
Sorry to be a pain Andi, but...
I agree completely. Can't we just call the damn thing DateTime stick it
into
RC1 of PHP 5.2, and move on?
It doesn't entirely resolve the problem. There's another class in there too.
in ext/date:
typedef struct _php_date_obj php_date_obj;
typedef struct _php_
Didn't see this but I did :)
Andi
> -Original Message-
> From: Andrei Zmievski [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 18, 2006 10:13 AM
> To: Dmitry Stogov
> Cc: php-cvs@lists.php.net; internals@lists.php.net
> Subject: [PHP-DEV] Re: [PHP-CVS] New Memory Manager (Was:
> [PHP-C
I agree completely. Can't we just call the damn thing DateTime stick it into
RC1 of PHP 5.2, and move on?
Andi
> -Original Message-
> From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 18, 2006 7:25 PM
> To: John Coggeshall
> Cc: Andrei Zmievski; Steph Fox; Greg Beaver;
Hi Michael
Why not call it _DateTime or _Date? maintaining it in the future for BC
will then be something like php::_Date, not too bad I don't think.
It's a core class. You want to make it look like some private property?
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To u
Rasmus -
John's right, because PHP::PHPDateTime would have to become acceptable
syntax. Not the _only available_ syntax, but an acceptable one.
I don't see why that is necessarily the case. We can simply decide that
it isn't.
It isn't _necessarily_ the case but how on earth are you going t
On Tue, 2006-07-18 at 18:58 -0700, Rasmus Lerdorf wrote:
> > Regardless, we know it's coming and we know it'll have namespacing
> > support. If we do PHPDateTime right now we'll have PHP::PHPDateTime
> > later, and that's just wonky.
>
> Why would it be PHP::PHPDateTime ? An extra alias here isn
On 7/19/06, Rasmus Lerdorf <[EMAIL PROTECTED]> wrote:
Because there is absolutely no reason to deliberately break our
installed base for a single version when it is quite arbitrary what we
call this class. We know for a fact that calling it Date will be
problematic. I also don't think a singl
Steph Fox wrote:
Regardless, we know it's coming and we know it'll have namespacing
support. If we do PHPDateTime right now we'll have PHP::PHPDateTime
later, and that's just wonky.
Why would it be PHP::PHPDateTime ? An extra alias here isn't going to
hurt very much. We are not talking about
Steph Fox wrote:
Rasmus,
Regardless, we know it's coming and we know it'll have namespacing
support. If we do PHPDateTime right now we'll have PHP::PHPDateTime
later, and that's just wonky.
Why would it be PHP::PHPDateTime ? An extra alias here isn't going
to hurt very much. We are not tal
John Coggeshall wrote:
On Tue, 2006-07-18 at 18:58 -0700, Rasmus Lerdorf wrote:
Regardless, we know it's coming and we know it'll have namespacing
support. If we do PHPDateTime right now we'll have PHP::PHPDateTime
later, and that's just wonky.
Why would it be PHP::PHPDateTime ? An extra alias
On Wed, 2006-07-19 at 03:58 +0200, Steph Fox wrote:
> John's right, because PHP::PHPDateTime would have to become acceptable
> syntax. Not the _only available_ syntax, but an acceptable one.
Unless you're proposing that we automagically parse class names so that
$a = new PHP::DateTime();
$b = ne
Rasmus,
Regardless, we know it's coming and we know it'll have namespacing
support. If we do PHPDateTime right now we'll have PHP::PHPDateTime
later, and that's just wonky.
Why would it be PHP::PHPDateTime ? An extra alias here isn't going to
hurt very much. We are not talking about hundred
On Wed, 2006-07-19 at 03:29 +0200, Steph Fox wrote:
> Rasmus, I'm sorry but I can't agree with you. When we get namespacing it'll
> make perfect sense to have PHP::Foo(). Until then, it makes no sense
> whatsoever to me to mess about with plain names for root classes. We aren't
> breaking 'tousa
V6 is not a hindrance to V5 and is at least 9-12 months away (for an
alpha).
I'm just looking at it from the PoV of someone with a lot of legacy code to
upgrade. If I knew Unicode support was on the way, I'd be hanging out for
that before I did anything other than maintenance work on that code
Regardless, we know it's coming and we know it'll have namespacing
support. If we do PHPDateTime right now we'll have PHP::PHPDateTime
later, and that's just wonky.
Why would it be PHP::PHPDateTime ? An extra alias here isn't going to
hurt very much. We are not talking about hundreds of class
Hi Rasmus,
But having PHPFoo does not in any way prevent PHP::Foo() in a future
version. Not namespacing it in 5.2 and then namespacing it in 6 means we
break stuff for one version for no reason. The "screw you guys, you
should namespaced your stuff" argument is the least userfriendly approa
John Coggeshall wrote:
On Tue, 2006-07-18 at 18:44 -0700, Andrei Zmievski wrote:
V6 is not a hindrance to V5 and is at least 9-12 months away (for an
alpha).
Regardless, we know it's coming and we know it'll have namespacing
support. If we do PHPDateTime right now we'll have PHP::PHPDateTime
John Coggeshall wrote:
On Wed, 2006-07-19 at 03:29 +0200, Steph Fox wrote:
Rasmus, I'm sorry but I can't agree with you. When we get namespacing it'll
make perfect sense to have PHP::Foo(). Until then, it makes no sense
whatsoever to me to mess about with plain names for root classes. We aren't
Which is why I proposed namespaces for 5_3.
-Andrei
On Jul 18, 2006, at 6:45 PM, John Coggeshall wrote:
On Tue, 2006-07-18 at 18:44 -0700, Andrei Zmievski wrote:
V6 is not a hindrance to V5 and is at least 9-12 months away (for an
alpha).
Regardless, we know it's coming and we know it'll h
On Tue, 2006-07-18 at 18:44 -0700, Andrei Zmievski wrote:
> V6 is not a hindrance to V5 and is at least 9-12 months away (for an
> alpha).
Regardless, we know it's coming and we know it'll have namespacing
support. If we do PHPDateTime right now we'll have PHP::PHPDateTime
later, and that's just
V6 is not a hindrance to V5 and is at least 9-12 months away (for an
alpha).
-Andrei
On Jul 18, 2006, at 6:32 PM, Steph Fox wrote:
We could put namespace support into 5.3.
Go Andrei :)
But it will push PHP 5 adoption, and I suspect what PHP really
wants and needs is an all-rounder v6.
We could put namespace support into 5.3.
Go Andrei :)
But it will push PHP 5 adoption, and I suspect what PHP really wants and
needs is an all-rounder v6.
-Andrei
On Jul 18, 2006, at 6:24 PM, Steph Fox wrote:
Andi Gutmans wrote:
[snip]
an early point and we should make the right decisio
We could put namespace support into 5.3.
-Andrei
On Jul 18, 2006, at 6:24 PM, Steph Fox wrote:
Andi Gutmans wrote:
[snip]
an early point and we should make the right decision now. I'd
prefer that
from now on going forward we prefix all new classes with Php.
In PHP 6, once
This is a go
Steph, I think prefixing internal classes is the most userfriendly
approach actually as it leaves these top-level names to userspace code and
prevents future conflicts. We are talking about classes here, so it isn't
like they get typed very often either. You instantiate the class and then
nam
Ilia -
I am not going to release RC1 until we've decided on this issue, that
much is certain.
good :) I didn't think you would.
On 18-Jul-06, at 7:22 PM, John Coggeshall wrote:
On Wed, 2006-07-19 at 01:06 +0200, Derick Rethans wrote:
Delaying it to 5.3 is not an option. We already dela
Andi Gutmans wrote:
[snip]
an early point and we should make the right decision now. I'd prefer
that
from now on going forward we prefix all new classes with Php. In PHP 6,
once
This is a good solution. 3 extra characters for each class have not
hurt spl users (no reports of SPL-related car
Steph Fox wrote:
This is a good solution. 3 extra characters for each class have not
hurt spl users (no reports of SPL-related carpal tunnel syndrome yet,
right? :). It will make it simple to figure out whether a class is
internal (does it start with "Php?") and will eliminate all future
debate
On Jul 18, 2006, at 5:08 PM, Greg Beaver wrote:
Andi Gutmans wrote:
[snip]
an early point and we should make the right decision now. I'd
prefer that
from now on going forward we prefix all new classes with Php. In
PHP 6, once
This is a good solution. 3 extra characters for each class have
This is a good solution. 3 extra characters for each class have not
hurt spl users (no reports of SPL-related carpal tunnel syndrome yet,
right? :). It will make it simple to figure out whether a class is
internal (does it start with "Php?") and will eliminate all future
debate. I have no qualm
Andi Gutmans wrote:
[snip]
> an early point and we should make the right decision now. I'd prefer that
> from now on going forward we prefix all new classes with Php. In PHP 6, once
This is a good solution. 3 extra characters for each class have not
hurt spl users (no reports of SPL-related carpa
On Tue, 18 Jul 2006 17:02:28 -0700
[EMAIL PROTECTED] ("Andi Gutmans") wrote:
> Oops :)
>
>
> _
>
> From: Ilia Alshanetsky [mailto:[EMAIL PROTECTED] On Behalf Of Ilia
> Alshanetsky
> Sent: Tuesday, July 18, 2006 4:54 PM
> To: Andi Gutmans
> Subject: Re: [PHP-DEV] Re: PEAR::Date broken (W
Oops :)
_
From: Ilia Alshanetsky [mailto:[EMAIL PROTECTED] On Behalf Of Ilia
Alshanetsky
Sent: Tuesday, July 18, 2006 4:54 PM
To: Andi Gutmans
Subject: Re: [PHP-DEV] Re: PEAR::Date broken (Was: [PHP-CVS] cvs:
php-src(PHP_5_2) /ext/date php_date.c php_date.h)
Sounds good to me, but you
On 7/19/06, Andi Gutmans <[EMAIL PROTECTED]> wrote:
Didn't help. I'm building with experimental ZTS. If you can't reproduce I'll
take a look tomorrow.
I will try it too. I have a couple things to change too :)
Btw, I just created the branche in filter, it was not present in 5.2.
--Pierre
--
Didn't help. I'm building with experimental ZTS. If you can't reproduce I'll
take a look tomorrow.
Andi
> -Original Message-
> From: Pierre [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 18, 2006 4:20 PM
> To: Andi Gutmans
> Cc: Frank M. Kromann; internals@lists.php.net
> Subject: Re:
On Tue, 18 Jul 2006, Ilia Alshanetsky wrote:
> And we need to get a bit on track as well. Let's outline possible options for
> names, vote on them and move on to more important things.
>
> The two naming options available so far are:
>
> Option A: DateTime & DateTimeZone
That one is fine.
Deri
On 7/19/06, Marcus Boerger <[EMAIL PROTECTED]> wrote:
Hello Lukas,
the php developer community endlessly asked the pear community to
prefix their names. And like allways the only thing we get back is shut
up, or we dicuss that laterthins years, ever thought of starting
to discuss it finall
On Wed, 19 Jul 2006, Pierre wrote:
> On 7/19/06, Derick Rethans <[EMAIL PROTECTED]> wrote:
> > On Tue, 18 Jul 2006, Marcus Boerger wrote:
> >
> > > well i know you d a lot and had to slow down and have been on vacation.
> > > Yet the vast majority is still using php 4 and we are indeed facing a
>
Hello Andrei,
oh my godlet's have a few beers on that during oscon at the oregon
brewers festival :-)
best regards
marcus
Wednesday, July 19, 2006, 12:16:22 AM, you wrote:
> I just realized that it's the first time I used a quadruple pointer.
> Must celebrate.
> -Andrei
> On Jul 18,
Marcus Boerger wrote:
Hello Edin,
Ilia is th eRelease Master, so in PHP he is the list as we do not have
any acepted public list whatsoever. Again i don#t agree on that but still
it served us all. And if I know it and Steph knows it and even has it in
the weeklies, how come you still say we're
I am not going to release RC1 until we've decided on this issue, that
much is certain.
On 18-Jul-06, at 7:22 PM, John Coggeshall wrote:
On Wed, 2006-07-19 at 01:06 +0200, Derick Rethans wrote:
Delaying it to 5.3 is not an option. We already delayed it once.
Delay the RC -- It'll be in 5.2
Lukas's list does not mention enabling date class. Nor does any place
else.
Except an email from Ilia, which must be in the archives, but which you
still choose to ignore :-( Why? Because it doesn't fit?
Found it: http://www.zend.com/lists/php-dev/200605/msg00028.html
- Steph
Edin
--
Hello Edin,
Ilia is th eRelease Master, so in PHP he is the list as we do not have
any acepted public list whatsoever. Again i don#t agree on that but still
it served us all. And if I know it and Steph knows it and even has it in
the weeklies, how come you still say we're all liars?
best regard
On 7/19/06, Derick Rethans <[EMAIL PROTECTED]> wrote:
On Tue, 18 Jul 2006, Marcus Boerger wrote:
> well i know you d a lot and had to slow down and have been on vacation.
> Yet the vast majority is still using php 4 and we are indeed facing a
> lof of security issues and don't do our reputation
On Wed, 2006-07-19 at 01:06 +0200, Derick Rethans wrote:
> Delaying it to 5.3 is not an option. We already delayed it once.
Delay the RC -- It'll be in 5.2, when we've settled this issue.
John
> Derick
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://ww
Steph Fox wrote:
Lukas's list does not mention enabling date class. Nor does any place
else.
Except an email from Ilia, which must be in the archives, but which you
still choose to ignore :-( Why? Because it doesn't fit?
Ilia was wrong about it. Same as you have been. He said it was on the
On Tue, 18 Jul 2006, Steph Fox wrote:
> Yep, that's a fair point. But at the same time, PEAR should be namespacing
> their classes - and in fact the date class in PEAR is breaking PEAR's own
> coding standards in that respect. Why should classes internal to PHP have to
> care about a rogue PEAR cl
On Tue, 18 Jul 2006, Marcus Boerger wrote:
> well i know you d a lot and had to slow down and have been on vacation.
> Yet the vast majority is still using php 4 and we are indeed facing a
> lof of security issues and don't do our reputation good if keep taking
> long times between mini releases.
Lukas's list does not mention enabling date class. Nor does any place
else.
Except an email from Ilia, which must be in the archives, but which you
still choose to ignore :-( Why? Because it doesn't fit?
Edin
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: h
On 7/19/06, Andi Gutmans <[EMAIL PROTECTED]> wrote:
There's also a build error in ZTS in ext/filter and warnings in ext/date.
Can someone take a look?
-g -O2 -pthread -DZTS -c /home/andi/php5/ext/filter/filter.c -o
ext/filter/filter.lo
In file included from /home/andi/php5/ext/filter/php_filt
On Wed, 19 Jul 2006, Pierre wrote:
> > Well, you could already have started that in December as you simply knew
> > this was going to come up again. If you (pear, not pierre) want to keep
> > sticking the head in the sand that is fine, but don't come with comments
> > like the above then in order
Thanks for this wonderfull contribution. Can we now stop shooting PEAR
and start to consider the real solution to the real problemS?
Darnit Pierre, I thought you and I had already saved the world! Was that a
'no' from everybody else, then?
- Steph
--Pierre
--
PHP Internals - PHP Runtime
On Tue, 18 Jul 2006, Andi Gutmans wrote:
> PHP 6 will come with some big changes. We could have a compat flag that
> supports old-style classes PhpDate if needed.
That sounds like a bad idea... already coming up with kludges to work
around it :)
Derick
--
PHP Internals - PHP Runtime Developme
Hello John,
[...]
>> However I don't think that discussing it right before a RC release is
>> the right time. We better have to remove the controversial part (drop
>> the class, keep the functions) and take the time to discuss this
>> problem, generally and not only for Date.
> Did I miss somet
Delaying it to 5.3 is not an option. We already delayed it once.
No, it _is_ an option, it's just not one you like :) But seriously D,
Pierre's right about two things here. One is disruption to users, the other
is that there's only one sane name. If this discussion had been at the
beginning
On Tue, 18 Jul 2006, Andi Gutmans wrote:
> My $.02 and hopefully we can have a more focused discusion now, which isn't
> geared against Derick, but forward looking and considering all the other
> classes that will be coming down the pipeline and doing the right thing.
I think I already wrote that
On 7/19/06, Derick Rethans <[EMAIL PROTECTED]> wrote:
Delaying it to 5.3 is not an option. We already delayed it once.
Err!
You already did this bad trick once, doing it again is an insult.
And I'm taking it easy, I hardly contain what I think about your
commit. So please at least try to be
Derick Rethans wrote:
On Tue, 18 Jul 2006, Ilia Alshanetsky wrote:
And we need to get a bit on track as well. Let's outline possible options for
names, vote on them and move on to more important things.
The two naming options available so far are:
Option A: DateTime & DateTimeZone
That one
On 7/19/06, Derick Rethans <[EMAIL PROTECTED]> wrote:
On Tue, 18 Jul 2006, Pierre wrote:
> On 7/18/06, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
> >
> > Pierre,
> >
> > Will all due respect, option C is what we did when it came to 5.1, except
> > instead of 5.3 it was 5.2. Sure, we can delay t
On Wed, 19 Jul 2006, Steph Fox wrote:
> > These two classes need to be renamed if they are to go in
> > and I've proposed 2 different naming conventions just a few e-mails
> > ago. Perhaps if you were to vote on the names or second (or is it
> > 3rd) Pierre' s proposal to shelf date until future r
I've said it twice in the past few days, but I guess with the flurry
of messages you've missed it.
I think it would be useful for the functionality inside the date
extension to go in, but it cannot go in as class date & class
timezone.
Why not?
These two classes need to be renamed if they are
On 7/19/06, Derick Rethans <[EMAIL PROTECTED]> wrote:
On Wed, 19 Jul 2006, Pierre wrote:
> On 7/19/06, Derick Rethans <[EMAIL PROTECTED]> wrote:
> > On Tue, 18 Jul 2006, Marcus Boerger wrote:
> >
> > > well i know you d a lot and had to slow down and have been on vacation.
> > > Yet the vast maj
On Tue, 18 Jul 2006, John Coggeshall wrote:
> On Tue, 2006-07-18 at 13:33 -0700, Andi Gutmans wrote:
> > PHP 6 will come with some big changes. We could have a compat flag that
> > supports old-style classes PhpDate if needed.
>
> -100
John, your keyboard seems broken
Sure. Starts on Thursday.
-A
On Jul 18, 2006, at 3:54 PM, Marcus Boerger wrote:
Hello Andrei,
oh my godlet's have a few beers on that during oscon at the
oregon
brewers festival :-)
best regards
marcus
Wednesday, July 19, 2006, 12:16:22 AM, you wrote:
I just realized that it's t
On Tue, 18 Jul 2006, Pierre wrote:
> On 7/18/06, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
> >
> > Pierre,
> >
> > Will all due respect, option C is what we did when it came to 5.1, except
> > instead of 5.3 it was 5.2. Sure, we can delay this indefinitely, but I for
> > one would like some reso
I've said it twice in the past few days, but I guess with the flurry
of messages you've missed it.
I think it would be useful for the functionality inside the date
extension to go in, but it cannot go in as class date & class
timezone. These two classes need to be renamed if they are to go
On Tue, 18 Jul 2006, Ilia Alshanetsky wrote:
> While I'd love 4.4.3 to be the last release in the 4.X series, I suspect there
> would be at least 1 and probably 2 releases after it.
Yeah, it will continue until there is no need anymore.
Derick
--
Derick Rethans
http://derickrethans.nl | http:/
Hello Lukas,
the php developer community endlessly asked the pear community to
prefix their names. And like allways the only thing we get back is shut
up, or we dicuss that laterthins years, ever thought of starting
to discuss it finally?
Tuesday, July 18, 2006, 10:27:46 PM, you wrote:
> S
Hello Jani,
cool that makes four already :-)
Tuesday, July 18, 2006, 11:00:12 PM, you wrote:
> As do I.
> --Jani
> On Tue, 18 Jul 2006, Andi Gutmans wrote:
>> I second Ilia.
>>
>>
>> _
>>
>> From: Ilia Alshanetsky [mailto:[EMAIL PROTECTED] On Behalf Of Ilia
>> Alshanetsky
>>
There's also a build error in ZTS in ext/filter and warnings in ext/date.
Can someone take a look?
/bin/sh /home/andi/php5/libtool --silent --preserve-dup-deps --mode=compile
/home/andi/php5/meta_ccld -Iext/filter/ -I/home/andi/php5/ext/filter/
-DPHP_ATOM_INC -I/home/andi/php5/include -I/home/andi
Hi Marcus,
Marcus Boerger wrote:
Hello Edin,
it is nice to get you back on track on formalism now that it suits you.
(Hint inheritance rules and bla bla). However we never had any way of
any formalized todo we actually cared for.
I was talking about formalism in the language, not the develo
You're a 4 star general now ;-)
On 18-Jul-06, at 6:16 PM, Andrei Zmievski wrote:
I just realized that it's the first time I used a quadruple
pointer. Must celebrate.
-Andrei
On Jul 18, 2006, at 3:07 PM, Andrei Zmievski wrote:
+ zval varargs = NULL;
+ int *n_varargs = NULL
On 7/18/06, Andi Gutmans <[EMAIL PROTECTED]> wrote:
That's not exactly how I see it but let's wait for that until we make a
proposal. Suffice to say it'd be more like new PHP:Date() or import Date
from PHP; new Date(); Anyway, still not final proposal but just sending
this so that you know I don
I just realized that it's the first time I used a quadruple pointer.
Must celebrate.
-Andrei
On Jul 18, 2006, at 3:07 PM, Andrei Zmievski wrote:
+ zval varargs = NULL;
+ int *n_varargs = NULL;
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: htt
Hello all,
actually i should count better, Ilia does 5.2 so the next open RM
would be for 5.3. And since we are heading towards RC phase of 5.2
it is anyway time to look for an RM of upcoming 5.3.
best regards
marcus
Tuesday, July 18, 2006, 11:52:36 PM, you wrote:
> Hello Derick,
> well i kn
Hello Edin,
it is nice to get you back on track on formalism now that it suits you.
(Hint inheritance rules and bla bla). However we never had any way of
any formalized todo we actually cared for. If you look up the todo's most
close to a release of any prior version you'll find out two things.
On 7/18/06, Steph Fox <[EMAIL PROTECTED]> wrote:
Thanks for the clarification. Sounds like a mess :)
Yes indeed. And yet, I don't think a non-messy way exists. This is a
particular case, since we do not have namespaces and have to find a
trick to:
1) Not clash with easily written class names
Ilia Alshanetsky wrote:
On 18-Jul-06, at 5:42 PM, Edin Kadribasic wrote:
Which forum you think should be used for evaluating/selecting a
Release Master?
As far as I know people have always volunteered for this role, I don't
recall times we had excess of candidates for the position (I w
On 18-Jul-06, at 5:42 PM, Edin Kadribasic wrote:
Which forum you think should be used for evaluating/selecting a
Release Master?
As far as I know people have always volunteered for this role, I
don't recall times we had excess of candidates for the position (I
wonder why ;-)). Ultimately
That's not exactly how I see it but let's wait for that until we make a
proposal. Suffice to say it'd be more like new PHP:Date() or import Date
from PHP; new Date(); Anyway, still not final proposal but just sending
this so that you know I don't expect to be concatinating strings such as
making P
While I'd love 4.4.3 to be the last release in the 4.X series, I
suspect there would be at least 1 and probably 2 releases after it.
On 18-Jul-06, at 5:54 PM, Marco wrote:
Sorry to barge in here with my opinions but isnt this discussion a
little
mute?
How many more PHP 4 releases are you
Hello Lukas,
in a dreamworld everyone would prefix all obvious/easy names as they
are by their nature likely to cause clashes.
[Marcus falling a sleep and hitting the send key]
best regards
marcus
Tuesday, July 18, 2006, 4:31:11 PM, you wrote:
> Rasmus Lerdorf wrote:
>> I think we need to ren
Sorry to barge in here with my opinions but isnt this discussion a little
mute?
How many more PHP 4 releases are you expecting? Surely 4.4.3 should be the
last? (Baring any serious security flaws) IMO bug fixes should be reserved
for PHP 5.x releases only.
Regards
Marco
On Tue, 2006-07-18 at 16:54 -0400, John Coggeshall wrote:
> On Tue, 2006-07-18 at 13:33 -0700, Andi Gutmans wrote:
> > PHP 6 will come with some big changes. We could have a compat flag that
> > supports old-style classes PhpDate if needed.
>
> -100
>
*-10
Hi Olivier,
On 7/18/06, Steph Fox <[EMAIL PROTECTED]> wrote:
I'm probably being dim here, but how is this going to pan out for BC?
Either
now, or when PHP 6 comes along and we (presumably) go from PhpDate to
Php::Date? (What am I missing?)
PHPDate would still exists as an alias for BC. The
Hello Derick,
well i know you d a lot and had to slow down and have been on vacation.
Yet the vast majority is still using php 4 and we are indeed facing a
lof of security issues and don't do our reputation good if keep taking
long times between mini releases. If now Pierre thinks he can do faster
I know I only lurk here usually, and this may be a daft idea but if I
don't throw it in the water I'll never know if it can float.
Why not allow classes and functions be overridden? For example, if I
define a function named mysql_query it replaces the existing function
and raises an E_STRICT error
On 7/18/06, Steph Fox <[EMAIL PROTECTED]> wrote:
I'm probably being dim here, but how is this going to pan out for BC? Either
now, or when PHP 6 comes along and we (presumably) go from PhpDate to
Php::Date? (What am I missing?)
PHPDate would still exists as an alias for BC. The advantage of
na
John Coggeshall wrote:
On Tue, 2006-07-18 at 22:41 +0200, Pierre wrote:
Yes, and in my book, my team collegues answer mails, don't ignore
users question and inform the rest of the team of their plans. If you
read the archives you will see that none of these points has been
fullfilled in the pas
Hello Dmitry,
well PEAR broke it's own rules here and somehow i feel PEAR needs to be
punished because PEAR never respected any PHP decision at all. Well you
might see that i am not a fan of PEAR. Actually i only use the minimum set
that allows me to run horde. Anyway the stone already fell into
On Tue, 2006-07-18 at 13:33 -0700, Andi Gutmans wrote:
> PHP 6 will come with some big changes. We could have a compat flag that
> supports old-style classes PhpDate if needed.
-100
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://
Andi Gutmans wrote:
I don't think question is only in regards to Date.
I think it's a bigger question on what the standard is for internal classes.
I couldn't agree more. The main question is who the unprefixed namespace
belongs to. I'd say it's either the core or the application but
certainl
Hello Pierre,
please just hold breath and keep that *** for yourself.
best regards
marcus
Tuesday, July 18, 2006, 6:17:09 PM, you wrote:
> Hello,
> On 7/18/06, Derick Rethans <[EMAIL PROTECTED]> wrote:
>> On Tue, 18 Jul 2006, Rasmus Lerdorf wrote:
>> This might also be something that might p
1 - 100 of 189 matches
Mail list logo
