Sorry for the double posts, Thunderbird's been acting weird lately...
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Greg Beaver wrote:
Jessie Hernandez wrote:
1) Do not allow constants in namespaces, just stick to functions and
classes.
I am confused as to why we need namespaced constants. Now that we have
class constants, this is a far better way to "namespace" constants. I
was also under the impressio
Greg Beaver wrote:
Jessie Hernandez wrote:
1) Do not allow constants in namespaces, just stick to functions and
classes.
I am confused as to why we need namespaced constants. Now that we have
class constants, this is a far better way to "namespace" constants. I
was also under the impressio
Pierre wrote:
> On Fri, 25 Nov 2005 18:32:14 -0600
> [EMAIL PROTECTED] (Greg Beaver) wrote:
>
>
>>Hi,
>>
>>I would like to propose these simple steps be taken:
>>
>>1) rename "date" to "PHP_Date"
>>2) reserve the "PHP_" prefix for all future core classes in PHP 5 (if
>>any) 3) when namespaces bec
Marcus Boerger wrote:
> Hello Guys,
>
> simply because the crew that actually develops php and tests it a lot
> before a release obviously doesn't use PEAR. And given the fact that pear
> was dropped from the main releases because it didn't fit into it
> functionality and compatibility wise anyw
Jessie Hernandez wrote:
> 1) Do not allow constants in namespaces, just stick to functions and
> classes.
I am confused as to why we need namespaced constants. Now that we have
class constants, this is a far better way to "namespace" constants. I
was also under the impression that this was far m
Ilia Alshanetsky wrote:
The attached patch is a possible solution to the date *crisis*, it
renames the class to PhpDate to avoid any namespace conflicts with pear
or custom user classes called date.
If there are no strong objection 5.1.1 (5.1.0 + this patch and nothing
else) goes out on Monday.
Bob Silva wrote:
$x = $y ? foo:bar:baz:stupid;
I think "stupid" is the key word here, by forcing the whitespace or (), you
are making the language itself stupid by not knowing how to parse itself.
I'm not a core developer, but I am pretty sure that this implementation will
never be accepted, s
> $x = $y ? foo:bar:baz:stupid;
I think "stupid" is the key word here, by forcing the whitespace or (), you
are making the language itself stupid by not knowing how to parse itself.
I'm not a core developer, but I am pretty sure that this implementation will
never be accepted, so change your argum
I object your honor!
This will set the stage for any other core objects to follow the same
convention. If namespaces are in PHPs future, design wise it would make more
sense to have them in a namespace ("PHP" seems to be popular), but if this
is released now as PhpDate, moving it to a namespace wo
I have to ask: what does renaming really buy us? The only purpose of
introducing this class in RC6, as far as I can tell, was to reserve the
'Date' name for future use. Since this goal is clearly unachievable,
what is the point of keeping a barely functional class around (as
PhpDate)? In my op
Hi Oliver,
Oliver Grätz wrote:
So if one only allows simple namespaces (no nesting), then one can see
that this need to be two namespace constants BUT one has to read the
whole line:
- one colon means simple constants
- three colons: two namespaces constants
- two colons: ERROR, undefined
If
Oliver Grätz schrieb:
> PS: How about a unicode symbol (egypt god Ra) as namespace operator.
> PHP6 will be all about unicode => Yeah, gazillions of new operator
> symbols. Or register a "PHP namespace separator symbol" that looks like
> the PHP logo. Just kidding...
Responding to myself: Why is
Jessie Hernandez schrieb:
>>> that's only one case,go with consts. now try
>>>$x = $y ? foo:bar:baz:stupid;
>>[... my two cents...]
> Thank you!!! This is exactly what happens with my patch now in this
> case, one constant named "foo:bar:baz:stupid" is parsed and a syntax
> error is produced be
The attached patch is a possible solution to the date *crisis*, it
renames the class to PhpDate to avoid any namespace conflicts with pear
or custom user classes called date.
If there are no strong objection 5.1.1 (5.1.0 + this patch and nothing
else) goes out on Monday.
Ilia
Index: ext/date/php_
Gareth Ardron schrieb:
> Jessie Hernandez wrote:
>
>>>Majority asking for namespaces != majority of php users.
>>
>>
>>How do you know? Have you conducted a poll?
My guess:
80.0% "What's a namespace?"
17.0% "I don't care."
2.9% "Yes please, weren't they already promised for 5.0 "
0.1% "Oh no.
Hello Oliver,
Oliver Grätz wrote:
Marcus Boerger schrieb:
Hello Jessie,
that's only one case,go with consts. now try
$x = $y ? foo:bar:baz:stupid;
That's nonsense. If I as a programmer cannot comprehend what it should
mean by looking at it then I shouldn't expect that from the language.
T
Marcus Boerger schrieb:
> Hello Jessie,
>
> that's only one case,go with consts. now try
> $x = $y ? foo:bar:baz:stupid;
That's nonsense. If I as a programmer cannot comprehend what it should
mean by looking at it then I shouldn't expect that from the language.
To me, this looks like the consta
Hello Bob,
Bob Silva wrote:
For what its worth (not much), I'd rather give up namespace constants and
use : rather than enforce whitespace which is just BAD from a language
perspective. Makes it feel like programming in bash. The concept behind
namespaces (in PHP at least) is rooted in OOP, so r
Maybe magic implementation was a better idea for [] overrieding like
for __get, __set, __isset and __unset stuff. For example __offsetGet,
__offsetSet, __offsetUnset and __offsetExists (or __offsetIsset). This
way people will be free using return by ref or not and also may
implement only some of th
I think a more accurate statement would be that the majority of php users
that prefer the OO features would prefer namespaces. I also think namespaces
could lead to what PEAR attempted to do in the first place. To create a
Standard PHP Library (hmm, that acronym looks familiar) for people to use
th
For what its worth (not much), I'd rather give up namespace constants and
use : rather than enforce whitespace which is just BAD from a language
perspective. Makes it feel like programming in bash. The concept behind
namespaces (in PHP at least) is rooted in OOP, so requiring a class just to
have c
Derick,
I am not sure where you came up with this idea, but it's patently
untrue. Core and userland have to co-exist, and that means cooperation,
not blatant disregard for thousands of users out there. Unless you're
speaking only for yourself, and in that case, I hope your upcoming
vacation i
Derick,
That's a pretty selfish point of view you have there. So, as long as
your code works, screw everyone else?
- Andrei
On Nov 25, 2005, at 2:57 AM, Derick Rethans wrote:
Yes, and that will break code again as I just explained to Sebastian
Kettler. And it will break *my* code ;-)
--
Jessie Hernandez wrote:
Majority asking for namespaces != majority of php users.
How do you know? Have you conducted a poll?
Ok,fair enough, I haven't - but neither have you.
Until there's any degree of certainty as to how many users this impacts
upon I don't think you can say that one w
On 2005-11-25, Lester Caine <[EMAIL PROTECTED]> wrote:
> That is one I am following with interest, and I have a large archive of
> unicode data ready to apply to the results :) But *PLEASE* can we have
> windows builds to play with from time to time ;) Some of us still do not
> have the tools to
On Fri, 25 Nov 2005 18:32:14 -0600
[EMAIL PROTECTED] (Greg Beaver) wrote:
> Hi,
>
> I would like to propose these simple steps be taken:
>
> 1) rename "date" to "PHP_Date"
> 2) reserve the "PHP_" prefix for all future core classes in PHP 5 (if
> any) 3) when namespaces become available, reserve
Hello Gareth,
Gareth Ardron wrote:
Majority asking for namespaces != majority of php users.
How do you know? Have you conducted a poll?
Regards,
Jessie
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Fri, 25 Nov 2005, Rasmus Lerdorf wrote:
We need to fix this date thing along with the Digest Auth mixup and get a
5.1.1 out the door soon. I see Ilia committed a fix for the Digest Auth
thing, so assuming that this fix works, we just need to figure out what to do
with this date class. W
Jessie Hernandez wrote:
Hi Chris,
Christian Schneider wrote:
PS: I'd rather have : for namespaces with the whitespace restriction
for ? a:x : b:y than the confusing (escaping characters outside of a
string?) backslash.
- Chris
I completely agree, and as I said before, I suspect the maj
On Fri, 2005-11-25 at 20:07, Ken Tossell wrote:
> Not to start a flame war, but...
>
> How about STD, Std, or something similar? It certainly works for... that
> language... that has multiple implementations of the standard classes.
> It can't hurt to play to people's comfort when the change doesn
Not to start a flame war, but...
How about STD, Std, or something similar? It certainly works for... that
language... that has multiple implementations of the standard classes.
It can't hurt to play to people's comfort when the change doesn't really
affect PHP in any major way. :)
But yes, a stan
Hi Chris,
Christian Schneider wrote:
PS: I'd rather have : for namespaces with the whitespace restriction for
? a:x : b:y than the confusing (escaping characters outside of a
string?) backslash.
- Chris
I completely agree, and as I said before, I suspect the majority who are
asking for n
Marcus Boerger wrote:
here again namespaces would be perfect. Given a lib that doesn't prefix
you'd simply do:
namespace LibNameHere { reqire "some_lib_include"; }
and be done...wohooo :-)
Only if newly introduced PHP core classes use a namespace too. You'll
have to use PHP\Date (or the like
Ian P. Christian wrote:
On Friday 25 November 2005 22:15, Rasmus Lerdorf wrote:
It is completely inconsistent
with the rest of PHP.
like how its case sensitive except when it's not and how array functions
start array_, except when they don't. if (): is valid, while(): is valid,
but you
Hi,
I would like to propose these simple steps be taken:
1) rename "date" to "PHP_Date"
2) reserve the "PHP_" prefix for all future core classes in PHP 5 (if any)
3) when namespaces become available, reserve "PHP" for all future
internal classes
Greg
--
PHP Internals - PHP Runtime Development
On Friday 25 November 2005 22:15, Rasmus Lerdorf wrote:
> It is completely inconsistent
> with the rest of PHP.
like how its case sensitive except when it's not and how array functions
start array_, except when they don't. if (): is valid, while(): is valid,
but you can't do it with switch,
Marcus Boerger wrote:
> Hello Helgi,
>
> obviously one problem is that PEAR does ignore coding standards. Classes
> should be prefixed in both pear and core. And neither Date nor File is in
> any way prefixed. In th end all we see here is that we want namespaces asap.
I absolutely agree with th
Hi Sara,
Sara Golemon wrote:
Forcing whitespace here isn't an option. It is completely
inconsistent with the rest of PHP.
It's also a conversation that was had before PHP5.0 was ever released
(when namespaces were first being attempted).
Anyone remember the term "syntactic sugar"?
You ma
"Rasmus Lerdorf" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Jessie Hernandez wrote:
> > Hi Marcus,
> >
> > Marcus Boerger wrote:
> >> Hello Jessie,
> >>
> >> that's only one case,go with consts. now try
> >> $x = $y ? foo:bar:baz:stupid;
> >>
> >> now what?
> >>
> >> best rega
Rasmus Lerdorf wrote:
$x = $y ? foo:bar : baz:stupid;
Forcing whitespace here isn't an option. It is completely inconsistent
with the rest of PHP.
-Rasmus
This is only one isolated case, though, and even then, it only happens
with constants (classes don't work anyways here and don't
Here it'll fail. My patch is basically allowing colons inside the
class/function/constant name, so whitespace here is _crucial_, i.e., the
following example WOULD work:
>
$x = $y ? foo:bar : baz:stupid;
Forcing whitespace here isn't an option. It is completely inconsistent
with the rest of
Hello Rasmus,
Friday, November 25, 2005, 11:15:36 PM, you wrote:
> Jessie Hernandez wrote:
>> Hi Marcus,
>>
>> Marcus Boerger wrote:
>>> Hello Jessie,
>>>
>>> that's only one case,go with consts. now try
>>> $x = $y ? foo:bar:baz:stupid;
>>>
>>> now what?
>>>
>>> best regards
>>> marcus
>>>
>>
Jessie Hernandez wrote:
Hi Marcus,
Marcus Boerger wrote:
Hello Jessie,
that's only one case,go with consts. now try
$x = $y ? foo:bar:baz:stupid;
now what?
best regards
marcus
Here it'll fail. My patch is basically allowing colons inside the
class/function/constant name, so whitespace
Hi Marcus,
Marcus Boerger wrote:
Hello Jessie,
that's only one case,go with consts. now try
$x = $y ? foo:bar:baz:stupid;
now what?
best regards
marcus
Here it'll fail. My patch is basically allowing colons inside the
class/function/constant name, so whitespace here is _crucial_, i.e.,
Rasmus Lerdorf wrote:
Are you saying this works?
namespace ns {
function foo() { }
}
function foo() {}
echo true ? ns:foo():foo();
Looks very confusing to me.
-Rasmus
Just tested that, and yes, it does work. If you think about it though,
this is excellent. A function foo() in my names
Hello Jessie,
that's only one case,go with consts. now try
$x = $y ? foo:bar:baz:stupid;
now what?
best regards
marcus
Friday, November 25, 2005, 10:52:51 PM, you wrote:
> Hello Rasmus,
> Rasmus Lerdorf wrote:
>> Jessie Hernandez wrote:
>>>
>>> Why is "\" the only available character? Right
Rasmus Lerdorf wrote:
Are you saying this works?
namespace ns {
function foo() { }
}
function foo() {}
echo true ? ns:foo():foo();
even worse if you use a class constant inside the ternary ..
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: h
Jessie Hernandez wrote:
Hello Rasmus,
Rasmus Lerdorf wrote:
Jessie Hernandez wrote:
Why is "\" the only available character? Right now my patch is using
":" and it's working great (though against 5.1). Is ":" used in some
other way in PHP 6?
It clashes with the : in the ternary.
-Rasmus
Hello Rasmus,
Rasmus Lerdorf wrote:
Jessie Hernandez wrote:
Why is "\" the only available character? Right now my patch is using
":" and it's working great (though against 5.1). Is ":" used in some
other way in PHP 6?
It clashes with the : in the ternary.
-Rasmus
Not in my patch! I jus
Hello Bob,
Friday, November 25, 2005, 9:33:45 PM, you wrote:
> That follows my sentiment, I think namespace implementation should be
> fast-tracked before a PHP 6 release to give developers time to modify/adjust
> their code to work with core object classes.
> Personally, I think PHP shouldn't h
Jessie Hernandez wrote:
Hello Marcus,
Marcus Boerger wrote:
Guys it is sensless to discuss the namespace separator. The only
possibility
is \ and that's not because anybody at some meeting liked it. It is
the only
character that is freely available as in not conflicting with anything we
have
Hello Marcus,
Marcus Boerger wrote:
Guys it is sensless to discuss the namespace separator. The only possibility
is \ and that's not because anybody at some meeting liked it. It is the only
character that is freely available as in not conflicting with anything we
have right now and still availab
Bob Silva wrote:
That follows my sentiment, I think namespace implementation should be
fast-tracked before a PHP 6 release to give developers time to modify/adjust
their code to work with core object classes.
This is what I hope for. My current patch is based on the current
release of PHP 5.1
Sara Golemon wrote:
We can either roll back:
http://cvs.php.net/diff.php/php-src/ext/date/php_date.c?r1=1.43.2.20&r2=1.43.2.21&ty=u
or perhaps a better option is to rename that internal class for now
I vote for #ifdefing it out of PHP5, and renaming PECL::Date to iDate or
Datei for PHP6 (i
Rasmus Lerdorf wrote:
I think that is a pretty good idea actually. It's the uid matching that
is the problem. Having a way to restrict which commands the exec
functions can execute is sort of a separate thing that is snapped onto
the end of safe_mode.
We're a little distracted by 5.1, but
That follows my sentiment, I think namespace implementation should be
fast-tracked before a PHP 6 release to give developers time to modify/adjust
their code to work with core object classes.
Personally, I think PHP shouldn't have any classes within the global scope,
but have them beneath somethin
On Fri, 25 Nov 2005 20:48:28 +0100
[EMAIL PROTECTED] (Marcus Boerger) wrote:
> And it doesn't help to shout or whine along.
I do not consider pointing out the total lack of respect some
people suffer as whining or shouting. I do not consider to warn about a
critical problem (for many people at l
On Fri, 25 Nov 2005 19:49:04 -
[EMAIL PROTECTED] ("Nuno Lopes") wrote:
> >I must say that I feel deceived by this.
> > Derick and I agreed that this won't be enabled for 5.1, and he then
> > took advantage of the fact that release managers changed to enable
> > his class. Doesn't leave a good
Hello Oliver,
feel free to write an interface that supports return by reference and be
done.
Having ArrayAccess in use we had to chose one of two possibilities. First
go with return by reference and second go with return by copy. We chose
return by copy simply because that was the intended us
Hello Matthias,
i think you didn't understand the whole point here. Naming something
after an every day word just like 'Date' is like screaming for problems in
bigger scenarios. It is a beginners mistake to not prefix such stuff.
And if you weren't in a big project - well then simply rename your
Marcus Boerger wrote:
p.s.: Regarding pear if pear is so important it would be nice if pear was at
least 5.0 code. All of it.
This statement is ridiculous and disappoints me, Marcus.
Regards,
--
Michael - http://dev.iworks.at/ext-http/http-functions.html.gz
--
PHP Internals - PHP Runtime De
Hello Sascha,
Friday, November 25, 2005, 1:36:11 PM, you wrote:
> On Fri, 25 Nov 2005, Derick Rethans wrote:
>> On Fri, 25 Nov 2005, Sascha Schumann wrote:
>>
> There is no mentioning of "PHP reserves the classname "Date"
> starting with PHP 5.1. Audit your source code for the use of
Hello Ilia,
to me PhpDate would be nice :-))
Friday, November 25, 2005, 2:43:43 PM, you wrote:
> Sascha Schumann wrote:
>> There is no suitable alternative for the 5.1 branch.
> Assuming that is the case we need to either rename ext/date's date class
> or ifdef it away. If we rename it,
Hello Andi,
Friday, November 25, 2005, 6:43:25 PM, you wrote:
> BTW, just to clarify, I am not against a Date class (whatever its
> name) in the long run but I think it'd probably be a combination of
> work Derick, Pierre and new contributions.
Yes from my point of view there could coexist a b
Hello Guys,
simply because the crew that actually develops php and tests it a lot
before a release obviously doesn't use PEAR. And given the fact that pear
was dropped from the main releases because it didn't fit into it
functionality and compatibility wise anyway i see no reason to change this
I must say that I feel deceived by this.
Derick and I agreed that this won't be enabled for 5.1, and he then took
advantage of the fact that release managers changed to enable his class.
Doesn't leave a good taste in my mouth and it shouldn't happen again in
future.
Andi
Just to clarify, it
Sara Golemon schrieb:
> ArrayAccess interface for the dimension read/write.
Just to bring the issue up agaian: The current ArrayAccess
implementation does not allow for proper simulation of arrays. This has
been "broken by fixing" (tm) the method prototypes not to allow "&"
anymore in interface im
Hello Guys,
Friday, November 25, 2005, 4:18:40 PM, you wrote:
> Ian P. Christian schrieb:
>> I can't help but add that I couldn't agree more.
> Thanks. Keeps me warm that people are actually able to be nice.
> Even more important as our heating is broken and we've got -2°C.
> B. *g*
>> [...]
Hello Christian,
here again namespaces would be perfect. Given a lib that doesn't prefic
you'd simply d:
namespace LibNameHere { reqire "some_lib_include"; }
and be done...wohooo :-)
regards
marcus
Friday, November 25, 2005, 2:14:10 PM, you wrote:
> Ilia Alshanetsky wrote:
>> Defining class
$foo = $_APPLICTION['bar'];
php_application_object::read_dimension(zval *element) {
zval *baz = fetch_from_storage_mechanism(element);
return baz;
}
Can't you hack this together today in PHP?
You just need runkit to register the superglobal.
Sure, runkit for the suplerglobal, apc for
Lukas Smith wrote:
obviously one problem is that PEAR does ignore coding standards.
Classes
should be prefixed in both pear and core. And neither Date nor File is in
any way prefixed. In th end all we see here is that we want namespaces
asap.
Err, how are we supposed to prefix PEAR::Date?
Hello Matthias,
could you please change to an email client that doesn't scramble
the message id's?
marcus
p.s.: this issue nerves a lot since we loose context. And from time to time
it has to be mentioned it seems :-)
Friday, November 25, 2005, 1:33:12 PM, you wrote:
>> >> I have always main
Sara Golemon schrieb:
> I vote for #ifdefing it out of PHP5, and renaming PECL::Date to iDate or
> Datei for PHP6 (in keeping with mysql tradition).
Datei? Yikes, that's "file" in german and would raise confusion ;-)
OLLi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
Can't you hack this together today in PHP?
You just need runkit to register the superglobal.
--Wez.
On 11/25/05, Sara Golemon <[EMAIL PROTECTED]> wrote:
> > No, but PHP could provide a standardized frontend in the form of a
> > super-global that can have modular backends (like we have with
> > ex
No, but PHP could provide a standardized frontend in the form of a
super-global that can have modular backends (like we have with
ext/session). One backend could then use memcached as its data store.
Funny, I've been thinking of just the same thing The PHP5 OOP hooks are
just begging for tha
Matthias Pigulla wrote:
I still don't understand why - despite all the discussion here - the 5.1
release is still on the php.net website, being publicy announced and
there is not even a single hint what problems users might run into.
Every major company has a disaster recovery plan to make thi
We can either roll back:
http://cvs.php.net/diff.php/php-src/ext/date/php_date.c?r1=1.43.2.20&r2=1.43.2.21&ty=u
or perhaps a better option is to rename that internal class for now
I vote for #ifdefing it out of PHP5, and renaming PECL::Date to iDate or
Datei for PHP6 (in keeping with mysql tradi
> Von: Andi Gutmans [mailto:[EMAIL PROTECTED]
> BTW, just to clarify, I am not against a Date class (whatever its
> name) in the long run but I think it'd probably be a
> combination of work Derick, Pierre and new contributions.
It would be nice if there would be some 'official' statement as to
BTW, just to clarify, I am not against a Date class (whatever its
name) in the long run but I think it'd probably be a combination of
work Derick, Pierre and new contributions.
Andi
At 09:17 AM 11/25/2005, Andi Gutmans wrote:
I must say that I feel deceived by this.
Derick and I agreed that t
Christopher Kunz wrote:
Peter Brodersen wrote:
Well, safe_mode could prevent someone of doing a
shell_exec("cat /home/otheruser/web/config.php");
open_basedir can't do the same thing.
Even if open_basedir could restrict the location of the called
executable people could still upload a binary t
I must say that I feel deceived by this.
Derick and I agreed that this won't be enabled for 5.1, and he then
took advantage of the fact that release managers changed to enable
his class. Doesn't leave a good taste in my mouth and it shouldn't
happen again in future.
Andi
At 08:31 AM 11/25/20
Ilia Alshanetsky wrote:
Sascha Schumann wrote:
There is no suitable alternative for the 5.1 branch.
Assuming that is the case we need to either rename ext/date's date class
or ifdef it away. If we rename it, what to date_ex, DateTime, phpDate,
something else?
ifdef it away and throw a ni
Ilia Alshanetsky wrote:
Sascha Schumann wrote:
I've seen that text. It is hidden at the end of a paragraph
not related to the topic at all (something about class
constants). As such it is totally inadequate. There should
be a prominent point in the release announcement about
Matthias Pigulla wrote:
Well, safe_mode could prevent someone of doing a shell_exec("cat
/home/otheruser/web/config.php"); open_basedir can't do the same
thing.
We were in a continual losing race against that sort of thing though.
In pretty much every single release there have been ways to
d
> On 11/25/05, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
> > Does this include anytime a new function/class is added we need to make
> > a prominent notice about since it reserves some name space?
> Yes of course, especially if it's such an obvious name like "date".
I disagree strongly. Date is
Ian P. Christian schrieb:
> I can't help but add that I couldn't agree more.
Thanks. Keeps me warm that people are actually able to be nice.
Even more important as our heating is broken and we've got -2°C.
B. *g*
> [...]
> Also, with you 100% on the \ syntax.
> Jessie and others - keep up the
Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
> Sascha Schumann wrote:
> > There is no suitable alternative for the 5.1 branch.
>
> Assuming that is the case we need to either rename ext/date's date class
> or ifdef it away. If we rename it, what to date_ex, DateTime, phpDate,
> something else?
On Friday 25 November 2005 12:25, Oliver Grätz wrote:
> Just two cents from a user's point of view: If you had put all the time
> you invested in this flame war about ONE class into already introducing
> namespaces (e.g. Core\Date or Core:Date or Core::Date, with a notev that
> I hate the \ syntax)
Rasmus Lerdorf wrote:
We can either roll back
+1
or perhaps a better option is to rename that internal class for now
--
Michael - http://dev.iworks.at/ext-http/http-functions.html.gz
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.ph
On 11/25/05, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
> Does this include anytime a new function/class is added we need to make
> a prominent notice about since it reserves some name space?
Yes of course, especially if it's such an obvious name like "date".
As opposed to some statements on thi
On Fri, 25 Nov 2005 08:43:43 -0500
[EMAIL PROTECTED] (Ilia Alshanetsky) wrote:
> Sascha Schumann wrote:
> > There is no suitable alternative for the 5.1 branch.
>
> Assuming that is the case we need to either rename ext/date's date
> class or ifdef it away. If we rename it, what to date_ex, D
Ilia Alshanetsky a écrit :
Romain,
You can find the 5.1 win32 binaries for most pecl extensions at:
http://pecl4win.php.net
Ilia
Thanks, i'll have a look there.
Romain
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sascha Schumann wrote:
> There is no suitable alternative for the 5.1 branch.
Assuming that is the case we need to either rename ext/date's date class
or ifdef it away. If we rename it, what to date_ex, DateTime, phpDate,
something else?
Ilia
--
PHP Internals - PHP Runtime Development Maili
Bottom line there is a problem and we need a fix for it. One solution
that has been suggested is to revert the date class and release 5.1.1,
but this means we pretty much deny ourselves the ability to have a
native "Date" class in PHP. Is this really the only fix we can come up with?
There i
On Fri, 25 Nov 2005, Ilia Alshanetsky wrote:
Sascha Schumann wrote:
Then I have to ask both of you: why is there no mentioning in
the release notes or the upgrading guide regarding "Date"
being reserved for PHP now?
There are notes in the guide, and I quote:
I've seen that t
> This rename would also give us a migration path where you could have a
> simple: class date extends date_ex { ... } wrapper which could then be
> removed when we have the final internal date class implementation.
IMVHO this is a good idea. At least I greatly appreciate that it
wouldn't break app
Sascha Schumann wrote:
> Then I have to ask both of you: why is there no mentioning in
> the release notes or the upgrading guide regarding "Date"
> being reserved for PHP now?
There are notes in the guide, and I quote:
"
Note that the new Date class exists at this point purely to allo
On Fri, 25 Nov 2005 08:21:42 -0500
[EMAIL PROTECTED] (Ilia Alshanetsky) wrote:
> Bottom line there is a problem and we need a fix for it. One solution
> that has been suggested is to revert the date class and release 5.1.1,
> but this means we pretty much deny ourselves the ability to have a
> nat
Ilia Alshanetsky wrote:
> Sascha Schumann wrote:
>
>>I've seen that text. It is hidden at the end of a paragraph
>>not related to the topic at all (something about class
>>constants). As such it is totally inadequate. There should
>>be a prominent point in the release announceme
1 - 100 of 161 matches
Mail list logo
