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
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
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
On Tue, 18 Jul 2006, Rasmus Lerdorf wrote:
But having PHPFoo does not in any way prevent PHP::Foo() in a future version.
Maybe not, but you're already trying to find workaround for a problem
that isn't even there yet...
Not namespacing it in 5.2 and then namespacing it in 6 means we break
On Wed, 19 Jul 2006, Lukas Smith wrote:
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
On Tue, 18 Jul 2006, Andrei Zmievski wrote:
I am not sure I like this idea of prefixing all the classes with PHP_. Having
PHP_TextIterator seems kind of wonky to me. Besides, I don't really see any
SPL_ prefixed classes, they are all either *Iterator or *Object.
See:
On Wed, 19 Jul 2006, Michael Gall wrote:
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
On Wed, 19 Jul 2006, Steph Fox wrote:
I don't think DateTime's more descriptive, I think it's a cop-out. And it's
also longer to type :)
It describes it better than just Date though.
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
On Tue, 18 Jul 2006, 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
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.
Since the early days of PHP4 everybody is using the plain names
I, as a mere PHP user really suggest you guys stick with DateTime and
TimeZone. If it's so core, you won't need to prefix TimeZone. It would feel
very natural to me without a DateTime_ prefix. Looking at this with a long
term view, I think prefixing it with PHP is a very bad idea. PHP6 is the
main
Hello Derick,
actually one of the reasons i pushed hard to get the exception hirarchy
in is the current acceptance of 'the early bird catches the fish'. We
should do somethign against it. Naming your classes no 'DateTime' and
'DateTimeZone' is pretty fair to me as it will also follow the current
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
Andi Gutmans wrote:
I agree completely. Can't we just call the damn thing DateTime stick it into
RC1 of PHP 5.2, and move on?
Gets my vote
( Now we just need browsers to return REAL timezone data ;) )
--
Lester Caine - G8HFL
-
L.S.Caine Electronic Services -
Hello Andrei,
we don't use '_' in class and method names. That said you must have
looked wrong:
[EMAIL PROTECTED] /usr/src/php-cvs $ php -r 'print_r(spl_classes());'|grep Spl
[SplFileInfo] = SplFileInfo
[SplFileObject] = SplFileObject
[SplObjectStorage] = SplObjectStorage
On Wed, 19 Jul 2006, Steph Fox wrote:
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.
Do you really want
Hello John,
where is the problem in having it as 'DateTime' or 'Date' in namespace
'PHP' and as 'PHPDateTime' or 'PHPDate' in the global namespace? We do
not have namespaces now but there is no technical reason to prevent that
from the beginning. So there is no preoblem here move a long forget
On Wed, 19 Jul 2006, Lester Caine wrote:
Andi Gutmans wrote:
I agree completely. Can't we just call the damn thing DateTime stick it into
RC1 of PHP 5.2, and move on?
Gets my vote
( Now we just need browsers to return REAL timezone data ;) )
http://talks.php.net/show/time-phptek6/30
Andi Gutmans wrote:
I agree completely. Can't we just call the damn thing DateTime stick it into
RC1 of PHP 5.2, and move on?
+1 for DateTime and DateTimezone; the flame was funny, but let's move on,
please.
--
Michael
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
Michael Wallner wrote:
Andi Gutmans wrote:
I agree completely. Can't we just call the damn thing DateTime stick
it into
RC1 of PHP 5.2, and move on?
+1 for DateTime and DateTimezone; the flame was funny, but let's move
on, please.
+1
regards,
Lukas
--
PHP Internals - PHP Runtime
Derick Rethans wrote:
On Wed, 19 Jul 2006, Lester Caine wrote:
Andi Gutmans wrote:
I agree completely. Can't we just call the damn thing DateTime stick it into
RC1 of PHP 5.2, and move on?
Gets my vote
( Now we just need browsers to return REAL timezone data ;) )
On 19.07.2006 11:46, Michael Wallner wrote:
Andi Gutmans wrote:
I agree completely. Can't we just call the damn thing DateTime stick it into
RC1 of PHP 5.2, and move on?
+1 for DateTime and DateTimezone;
+1
the flame was funny, but let's move on, please.
Yes, please.
--
Wbr,
Antony
-Original Message-
From: Lester Caine [mailto:[EMAIL PROTECTED]
Sent: 19 July 2006 09:53
To: Derick Rethans
Cc: internals@lists.php.net
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)
Derick Rethans wrote
On Wed, 19 Jul 2006, Michael Wallner wrote:
Andi Gutmans wrote:
I agree completely. Can't we just call the damn thing DateTime stick it into
RC1 of PHP 5.2, and move on?
+1 for DateTime and DateTimezone; the flame was funny, but let's move on,
please.
I thought this was already agreed
On 7/19/06, Jani Taskinen [EMAIL PROTECTED] wrote:
On Wed, 19 Jul 2006, Michael Wallner wrote:
Andi Gutmans wrote:
I agree completely. Can't we just call the damn thing DateTime stick it into
RC1 of PHP 5.2, and move on?
+1 for DateTime and DateTimezone; the flame was funny, but let's move
Actually, TextIterator a PHP 6-only class so it will be inside a
namespace anyway.
-Andrei
On Jul 19, 2006, at 12:13 AM, Derick Rethans wrote:
Well, we already use prefixes for extensions, such as Soap* and DOM*
and
Spl*... so I don't see anything inheritly wrong with DateTime and
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 get
sane names in
On Wed, 2006-07-19 at 10:35 +0200, Marcus Boerger wrote:
where is the problem in having it as 'DateTime' or 'Date' in namespace
'PHP' and as 'PHPDateTime' or 'PHPDate' in the global namespace? We do
not have namespaces now but there is no technical reason to prevent that
from the beginning.
On Wed, 2006-07-19 at 10:49 +0200, Lukas Smith wrote:
+1 for DateTime and DateTimezone; the flame was funny, but let's move
on, please.
+1 from me.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Wed, 2006-07-19 at 09:40 +0200, Marcus Boerger wrote:
A single alpha released pecl extension has a problem, well that imo is
not that bad conflict and can be solved before it is being released.
I wonder if The Perl guys check every single CPAN extension before
introducing a new keyword or
On Wed, 19 Jul 2006 14:02:56 -0400
[EMAIL PROTECTED] (John Coggeshall) wrote:
On Wed, 2006-07-19 at 09:40 +0200, Marcus Boerger wrote:
A single alpha released pecl extension has a problem, well that imo
is not that bad conflict and can be solved before it is being
released.
I wonder if
On Wed, 19 Jul 2006 14:02:56 -0400
[EMAIL PROTECTED] (John Coggeshall) wrote:
On Wed, 2006-07-19 at 09:40 +0200, Marcus Boerger wrote:
A single alpha released pecl extension has a problem, well that imo
is not that bad conflict and can be solved before it is being
released.
I wonder if The
Steph Fox wrote:
Please, just make a clear decision, stick to it, and tell us what it is,
we will adapt our coding standards to whatever is decided.
Either:
1) internals declares all top-level classes, use an unprefixed name (no
_) at your own risk
2) internals grabs PHP or Php as a
Hello Greg,
this whole thread unfortunatley shows that nobody is reading our
provided documentation, see excerpt from CODING_STANDARDS:
[7] Classes should be given descriptive names. Avoid using abbreviations where
possible. Each word in the class name should start with a capital letter,
On Tue, 18 Jul 2006, Dmitry Stogov wrote:
This patch breaks PEAR::Date (because it reserves class Date) and all
applications those use it.
That was kinda obvious and also the reason why it was not in PHP 5.1 as
we added this class too late.
Was this break discussed?
Yes, this was discussed
Derick Rethans wrote:
Yes, this was discussed in December last year. The PEAR team was plenty
aware of this issue as well and had enough time to address it (about 7
months now).
Derick makes it sound that this was agreed. Sure there was a discussion.
Its an outright lie to suggest that any
Do we really like it in 5.2?
It was originally on the 5_2 TODO.
Yes, as we finally need the date support that has been ready for 8 months
now. Waiting any longer doesn't make sense either.
We do not need to break gazzillions of applications out there.
What gazzillions of applications are
Steph Fox wrote:
Do we really like it in 5.2?
It was originally on the 5_2 TODO.
Where? Never seen it. Heard Derick lie to people about it a few times.
Yes, as we finally need the date support that has been ready for 8
months now. Waiting any longer doesn't make sense either.
We do not
Derick Rethans wrote:
On Tue, 18 Jul 2006, Steph Fox wrote:
AFAICR the reason it was taken off the public TODO was purely to prevent WW4
breaking out on the spot. I expect Derick (and probably Ilia) had similar
feelings about it now.
Not at all. I don't mind a *civilized* discussion about
Steph Fox wrote:
Do we really like it in 5.2?
It was originally on the 5_2 TODO.
Where? Never seen it. Heard Derick lie to people about it a few times.
http://www.zend.com/zend/week/week287.php#Heading2
quote
Andreas Korthaus wanted to know about the fate of issues past; the date
AFAICR the reason it was taken off the public TODO was purely to prevent
WW4
breaking out on the spot. I expect Derick (and probably Ilia) had similar
feelings about it now.
Not at all. I don't mind a *civilized* discussion about it.
You need to be civilized in the first place for such a
Steph Fox wrote:
Steph Fox wrote:
Do we really like it in 5.2?
It was originally on the 5_2 TODO.
Where? Never seen it. Heard Derick lie to people about it a few times.
http://www.zend.com/zend/week/week287.php#Heading2
So your statemetn from above is false. It has never been on
Steph Fox wrote:
Please, Edin, it doesn't behove you to start name-calling.
Listen, I *am* pissed off. If everyone thought this is going to raise
some resistance on the internals so lets screw them morons and just go
ahead and commit stuff because we're smarter than them how far would
PHP
It was originally on the 5_2 TODO.
Where? Never seen it. Heard Derick lie to people about it a few times.
http://www.zend.com/zend/week/week287.php#Heading2
So your statemetn from above is false. It has never been on PHP 5.2 TODO.
Zend weeklies are something completely different,
Steph Fox wrote:
It was originally on the 5_2 TODO.
^^^
Read it. Understand that this is false.
Edin
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Steph Fox wrote:
What gazzillions of applications are going to get broken? Can you name
one outside PEAR?
I'm sure everyone realizes this, but it's not just PEAR, it's any
application that uses the Date class. The Date class can be renamed, but
that won't automatically fix everyone who uses
On Tue, 18 Jul 2006, Steph Fox wrote:
AFAICR the reason it was taken off the public TODO was purely to prevent WW4
breaking out on the spot. I expect Derick (and probably Ilia) had similar
feelings about it now.
Not at all. I don't mind a *civilized* discussion about it.
Derick
--
PHP
On Tue, 18 Jul 2006, Steph Fox wrote:
Steph Fox wrote:
What gazzillions of applications are going to get broken? Can you name one
outside PEAR?
I'm sure everyone realizes this, but it's not just PEAR, it's any
application that uses the Date class. The Date class can be renamed, but
Derick Rethans wrote:
Because PEAR doesn't really work with PHP 5 ;-) (a joke people). But
seriously there can be conflicts here, and you can't really disprove
that with 5 days of a .0 release...However I do think that gazillions
is a bit of an overstatement.
Sure. FYU it was meant as many
Steph Fox wrote:
What gazzillions of applications are going to get broken? Can you name
one outside PEAR?
I'm sure everyone realizes this, but it's not just PEAR, it's any
application that uses the Date class. The Date class can be renamed, but
that won't automatically fix everyone who uses
Aaron, I'm going to repeat it again: in the 5.1.0 release, where the Date
class existed in PHP, after 5 days there were NO bug reports. None, nix,
nada.
Because PEAR doesn't really work with PHP 5 ;-) (a joke people).
That may be a joke, but it's wholly possible that the PHP 5 using
Because PEAR doesn't really work with PHP 5 ;-) (a joke people). But
seriously there can be conflicts here, and you can't really disprove that
with 5 days of a .0 release...However I do think that gazillions is a
bit of an overstatement.
Sure. FYU it was meant as many applications.
But
On Tue, 2006-07-18 at 20:25 +0200, Edin Kadribasic wrote:
But breaking even a few or both is still reckless, irresposible
behaviour when all that is needed to fix the breakage is rename the
class. Espacially because of all the bad publicity we get for breaking
backwards compatibility for no
Hey,
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.
We are just at the beginning of this stage in PHP's evolution, and I think
we need to agree on a standard that Date and other following classes will
all adhere to.
Although we already have quite a few classes in PHP I think we are still
at
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
we implement namespaces for classes (yep, on my todo) then we can
On 7/18/06, John Coggeshall [EMAIL PROTECTED] wrote:
On Tue, 2006-07-18 at 20:25 +0200, Edin Kadribasic wrote:
But breaking even a few or both is still reckless, irresposible
behaviour when all that is needed to fix the breakage is rename the
class. Espacially because of all the bad publicity
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
Steph stay on topic. Date follows current PEAR naming standards just
Hi Lukas,
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
Steph stay on topic. Date follows current PEAR naming standards just fine
and
-
From: Steph Fox [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 18, 2006 1:00 PM
To: Andi Gutmans; 'Derick Rethans'
Cc: 'Edin Kadribasic'; 'Dmitry Stogov';
internals@lists.php.net; 'Ilia Alshanetsky'
Subject: Re: [PHP-DEV] Re: PEAR::Date broken (Was: [PHP-CVS]
cvs: php-src(PHP_5_2) /ext/date
Hello,
On 7/18/06, Steph Fox [EMAIL PROTECTED] wrote:
If PHP 6 is going to introduce class namespaces it's pretty much a temporary
problem, no? Again, I have the feeling I'm missing something.
Yes, Lukas coment, you completelly miss it. But that's not the point
of this discussion.
--
PHP
PHP 6 will come with some big changes. We could have a compat flag that
supports old-style classes PhpDate if needed.
In any case, it's premature as we don't have this yet and it's not
relevant
to PHP 5. I just wanted to Fyi that it's something to consider.
It _is_ relevant to PHP 5, because
Given that PHP 6 far off target, I think we need to develop a
solution that works now. We've already waited too long given how many
classes were added in-core extensions since 5.0 was released. Just
like we have a naming convention for functions we need to decide on
one for classes as
I don't think prefixing things with PHP makes a lot of sense to me for
something like Date. For starters, it isn't very intuitive. But thinking
more long term why name the class PHPDate now only to rename it to
Date later when we get a PHP namespace? We're avoiding a BC break
today when adoption
Hi Pierre,
If PHP 6 is going to introduce class namespaces it's pretty much a
temporary
problem, no? Again, I have the feeling I'm missing something.
Yes, Lukas coment, you completelly miss it. But that's not the point
of this discussion.
Care to elucidate? Far as I'm aware the only
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 resolution on the issue.
But if the general consensus is to continue treading water, I guess
we can do that
broken (Was: [PHP-CVS] cvs:
php-src(PHP_5_2) /ext/date php_date.c php_date.h)
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 resolution on the issue. But if the general
Hello,
On 7/18/06, Ilia Alshanetsky [EMAIL PROTECTED] wrote:
Option A: DateTime DateTimeZone
Option B: PHPDate PHPTimezone
The only sane way:
Option C: Delay to 5.3, warn our users in the 5.2 release notes, use Date
That will be true for Date, File or whatever else we may use (Derick,
Zip
All,
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 resolution on the issue. But if the general consensus
is
to continue treading water, I guess we can do that too...
Hello,
On 7/18/06, Ilia Alshanetsky [EMAIL PROTECTED] wrote:
Option A: DateTime DateTimeZone
Option B: PHPDate PHPTimezone
The only sane way:
Option C: Delay to 5.3, warn our users in the 5.2 release notes, use Date
If you go with this, Pierre, I'll offer now to maintain a namespaced
On Tue, 2006-07-18 at 22:25 +0200, Pierre wrote:
- to start using the common names in general without a loud,
official and preemptive
warning to our users (meaning not from one minor to another)
I think we need people in charge of this specific topic. We're largely
developers after all, not
: 'Steph Fox'; 'Derick Rethans'; 'Edin Kadribasic'; 'Dmitry Stogov';
internals@lists.php.net
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)
Given that PHP 6 far off target, I think we need to develop a solution that
works now. We've
;
internals@lists.php.net
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)
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
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 resolution on the issue. But if the general consensus is
to
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
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:
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
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
(I do
: PEAR::Date broken (Was: [PHP-CVS]
cvs: php-src(PHP_5_2) /ext/date php_date.c php_date.h)
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
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, 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
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
, July 18, 2006 1:55 PM
To: Pierre
Cc: Andi Gutmans; Steph Fox; Derick Rethans; Edin Kadribasic; Dmitry Stogov;
internals@lists.php.net
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)
Pierre,
Will all due respect, option C
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:
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, 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 resolution on the
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...
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 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 releases
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 this
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:
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 a
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
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
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 something,
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
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 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 to
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:
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
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
1 - 100 of 135 matches
Mail list logo
