Hi all,
In our current codebase for PHP5.1 we've a class named 'Datetime' (I suppose
a lot of people is in the same situation). I'm wondering if there's any
chance
to add an ini directive in order to disable the definition of the new class.
I mean, we had a lot of PHP4 projects and, with two or three minor changes
we
got them working in PHP5 (as a matter of fact, we didn't experience almost
any
BC trouble... It was kind of easy). How could it be more difficult to
upgrade
from PHP5.1 to PHP5.2? It would be a nightmare too change every date
creation,
and, of course, the type hints. I'd really like to move to PHP5.2 because it
has a lot of really nice things.
Thanks.
Regards,
Mauro.
Mauro N. Infantino wrote:
Hi all,
In our current codebase for PHP5.1 we've a class named 'Datetime' (I suppose
a lot of people is in the same situation).
More people had one named Date, so we changed it from Date to DateTime.
You are going to have to change yours. Sorry.
-Rasmus
Hi all,
In our current codebase for PHP5.1 we've a class named
'Datetime' (I supposea lot of people is in the same situation). I'm wondering if there's
any
chance
to add an ini directive in order to disable the definition of the
new class.
Nil to none.
I mean, we had a lot of PHP4 projects and, with two or three minor
changes
we
got them working in PHP5 (as a matter of fact, we didn't experience
almost
any
BC trouble... It was kind of easy). How could it be more difficult to
upgrade
from PHP5.1 to PHP5.2? It would be a nightmare too change every date
creation,
and, of course, the type hints. I'd really like to move to PHP5.2
because ithas a lot of really nice things.
Avoid common namespaces and you'll make your application futureproof.
When developing a distributed application it is always a good idea to
prefix functions/class names with app name or some acronym to avoid
overly long names. The way things are going you are going to see more
and more classes being introduced by "core" PHP as well as the
growing number of PECL extensions out there and I am not even going
to mention the thousands of libraries out there.
Ilia Alshanetsky
P.S. If you absolutely must disable it, edit the source code and
rename the native class to DateTime2 or something similar.
Ilia Alshanetsky wrote:
Avoid common namespaces and you'll make your application futureproof.
I'm still wary of this approach because it puts the burden on 99% of the
code to be written (applications) instead of a small, controllable
subset (core and libraries).
When developing a distributed application it is always a good idea to
prefix functions/class names with app name or some acronym to avoid
overly long names. The way things are going you are going to see more
and more classes being introduced by "core" PHP as well as the growing
... which brings us back to the discussion of namespaces and which one
core classes should use ;-)
number of PECL extensions out there and I am not even going to mention
the thousands of libraries out there.
Those are less of a problem because you don't have to include them if
you don't want to.
- Chris
Ilia Alshanetsky wrote:
Avoid common namespaces and you'll make your application futureproof.
I'm still wary of this approach because it puts the burden on 99%
of the code to be written (applications) instead of a small,
controllable subset (core and libraries).
Translation: blame other people...
When developing a distributed application it is always a good idea
to prefix functions/class names with app name or some acronym to
avoid overly long names. The way things are going you are going to
see more and more classes being introduced by "core" PHP as well
as the growing... which brings us back to the discussion of namespaces and which
one core classes should use ;-)
The language should ALWAYS have the best names possible to simplify
development, because that means convenience for majority of users. No
matter how popular your app, PHP, the language is still hundreds if
not thousands of times more popular and as such needs of many
outweigh needs of the few.
number of PECL extensions out there and I am not even going to
mention the thousands of libraries out there.Those are less of a problem because you don't have to include them
if you don't want to.
You can use old PHP too, or modify the source code, it is "open
source" after-all.
Ilia Alshanetsky
Ilia Alshanetsky wrote:
Ilia Alshanetsky wrote:
Avoid common namespaces and you'll make your application futureproof.
I'm still wary of this approach because it puts the burden on 99% of
the code to be written (applications) instead of a small, controllable
subset (core and libraries).Translation: blame other people...
I'm not sure what you mean here. I was just doing a head count on who
has to come up with save names: A few core developers or all of the PHP
users.
The language should ALWAYS have the best names possible to simplify
development, because that means convenience for majority of users. No
While that's certainly true (and part of me is even thinking it is the
right approach) it means that each and everyone writing PHP code (which
means a big number of people with all different levels of experience)
has to care about naming. So it makes the language a little less simple
to use. That's all I'm saying.
matter how popular your app, PHP, the language is still hundreds if not
thousands of times more popular and as such needs of many outweigh needs
of the few.
A little thought experiment: Let's assume the number of application
classes (and the usage of those classes) is on average higher than those
of the core classes. Would that change the situation?
You can use old PHP too, or modify the source code, it is "open source"
after-all.
Come on, that can't be the solution. Think about hosting companies for
example.
Don't get me wrong: I'm not saying you're wrong, I'm just trying to
provide another point of view on the topic here which should be
considered IMHO.
- Chris
Hello Christian,
Sunday, November 5, 2006, 5:21:24 AM, you wrote:
Ilia Alshanetsky wrote:
Ilia Alshanetsky wrote:
The language should ALWAYS have the best names possible to simplify
development, because that means convenience for majority of users. No
While that's certainly true (and part of me is even thinking it is the
right approach) it means that each and everyone writing PHP code (which
means a big number of people with all different levels of experience)
has to care about naming. So it makes the language a little less simple
to use. That's all I'm saying.
We had problems with Date, DateTime and Time as all of those are common.
Should we name a class that represents data and time info name after say
'PhpDateTimeFart' so that there is no problem? Because if you think further
it might be commone to put Php into class names that deal with php... that
said wouldn't it be easier for the masses of people, that start using PHP,
to not having to read the manual each time a date time class is being used?
just my small thought on this
Best regards,
Marcus
Marcus Boerger wrote:
We had problems with Date, DateTime and Time as all of those are common.
I'm well aware of this and the discussion around it.
Should we name a class that represents data and time info name after say
'PhpDateTimeFart' so that there is no problem? Because if you think further
it might be commone to put Php into class names that deal with php... that
said wouldn't it be easier for the masses of people, that start using PHP,
to not having to read the manual each time a date time class is being used?
I'm willing to bet that the number of PhpDate classes out there is
considerably smaller then the number of Date classes.
[ You could theoretically even add an E_STRICT (or E_DEPRECATED ;-))
warning if class names starting with Php are used. ]
But my favourite solution would be to
a) have namespaces handling this issue
b) not introducing (many) more core classes before that
c) and thus not having to educate users to use prefixes (to have less
guidelines is a Good Thing(tm) IMHO)
I didn't want to restart the whole naming discussion really but point is
that it is still an open issue for the next (major) release and should
better be looked at sooner than later.
- Chris
This one time, at band camp, Christian Schneider cschneid@cschneid.com wrote:
But my favourite solution would be to
a) have namespaces handling this issue
So, we've come full circle.
PHP does not support namespaces, so you should be prefixing.
Kevin
--
"Democracy is two wolves and a lamb voting on what to have for lunch.
Liberty is a well-armed lamb contesting the vote."
You can't rely on people prefixing their classes. In libraries, yes, but in
applications, don't count on it too much.
- First of all, people use their classes a lot more than PHP core classes,
and so prefixing application classes is a big burden compared to prefixing
PHP core classes. - Second, with the active record design pattern becoming more popular,
database table-names are starting to dictate class names.
But I'm not saying PHP core classes should be prefixed. I think there's only
one real solution, which is the usage of namespaces, and I'm eagerly
awaiting their arrival in PHP.
You can't educate the whole world into using prefixes, because people simply
won't listen and will be stubborn. It just won't happen. The FUD is in not
knowing what classes will be added next and if the user's project will
suffer from it. I think these stubborn users are right (so I guess that
makes me a stubborn user). With namespaces this problem would not even
exist, and so it's PHP that needs to change, not the user approach.
-- Ron
"Christian Schneider" cschneid@cschneid.com wrote in message
news:454D6EDE.60202@cschneid.com...
Marcus Boerger wrote:
We had problems with Date, DateTime and Time as all of those are common.
I'm well aware of this and the discussion around it.
Should we name a class that represents data and time info name after say
'PhpDateTimeFart' so that there is no problem? Because if you think
further
it might be commone to put Php into class names that deal with php...
that
said wouldn't it be easier for the masses of people, that start using
PHP,
to not having to read the manual each time a date time class is being
used?I'm willing to bet that the number of PhpDate classes out there is
considerably smaller then the number of Date classes.
[ You could theoretically even add anE_STRICT(orE_DEPRECATED;-))
warning if class names starting with Php are used. ]But my favourite solution would be to
a) have namespaces handling this issue
b) not introducing (many) more core classes before that
c) and thus not having to educate users to use prefixes (to have less
guidelines is a Good Thing(tm) IMHO)I didn't want to restart the whole naming discussion really but point is
that it is still an open issue for the next (major) release and should
better be looked at sooner than later.
- Chris
Ron Korving wrote:
- First of all, people use their classes a lot more than PHP core classes,
and so prefixing application classes is a big burden compared to prefixing
PHP core classes.
Its quite trivial .. all people need to do is stick a single underscore
into their class name [1]. Thats all. They only need to really prefix
with anything a bit longer if they want to avoid name clashes with other
third party code.
- Second, with the active record design pattern becoming more popular,
database table-names are starting to dictate class names.
Err, where is the problem applying a default prefix in that scenario?
And sure if there is a sensible implementation for namespaces I am sure
we will get the feature. I have not yet heared any core people say that
they are against the feature in general.
regards,
Lukas
But my favourite solution would be to
a) have namespaces handling this issue
Not happening in 5.2 branch.
b) not introducing (many) more core classes before that
They will continue to be introduced as needs for them appear.
c) and thus not having to educate users to use prefixes (to have
less guidelines is a Good Thing(tm) IMHO)
I am not even going to bother with this one.
Ilia Alshanetsky
Ilia Alshanetsky wrote:
But my favourite solution would be to
a) have namespaces handling this issueNot happening in 5.2 branch.
I know. I'm talking about a long term solution.
b) not introducing (many) more core classes before that
They will continue to be introduced as needs for them appear.
Sure, I don't doubt that. I'm just describing my favourite scenario.
c) and thus not having to educate users to use prefixes (to have less
guidelines is a Good Thing(tm) IMHO)I am not even going to bother with this one.
So you don't think fewer rules are easier to learn and use? puzzled
You seem to be offended by something I said. I don't know what that was
but I'm apologizing anyway: I didn't mean to attack anyone here.
Regards,
- Chris
c) and thus not having to educate users to use prefixes (to have
less guidelines is a Good Thing(tm) IMHO)
I am not even going to bother with this one.So you don't think fewer rules are easier to learn and use? puzzled
There are no "rules" there is just one rule, that's not even specific
to PHP when you think of it. It is generally considered to be a good
practice to prefix your code with app name or similar to avoid
conflicts with other libraries and/or applications. When it comes to
this rule, I think it is one of the very few that are essential for
developers to learn.
Ilia Alshanetsky
Ilia Alshanetsky wrote:
There are no "rules" there is just one rule, that's not even specific to
PHP when you think of it. It is generally considered to be a good
practice to prefix your code with app name or similar to avoid conflicts
with other libraries and/or applications. When it comes to this rule, I
think it is one of the very few that are essential for developers to learn.
What about "do not trust user input"? Or "avoid copy/pasting code,
refactor instead"? Or "use descriptive identifiers"? Those are all
rules to be followed when programming. And the more there are the more
experience it takes to not get any of them wrong.
This would mean classes should be prefixed by extension name...
That is the common case, yes. In fact the date extension's classes
follow this convention to the letter. DateTime + DateTimeZone (Date
is the extension name).
Well, almost: DateTime is a date class, not a time class.
However, for native classes there maybe exceptions to simplify usage,
when a need for such exceptions arise this will be discussed on this list.
We're only talking about native classes anyway. And I think not bending
the rules simplify usage more than saving a couple of letters. Wasn't
that a lesson we learned from functions?
- Chris
Ilia Alshanetsky wrote:
There are no "rules" there is just one rule, that's not even
specific to PHP when you think of it. It is generally considered
to be a good practice to prefix your code with app name or similar
to avoid conflicts with other libraries and/or applications. When
it comes to this rule, I think it is one of the very few that are
essential for developers to learn.What about "do not trust user input"? Or "avoid copy/pasting code,
refactor instead"? Or "use descriptive identifiers"? Those are all
rules to be followed when programming. And the more there are the
more experience it takes to not get any of them wrong.
And your point is what? There are even more rules you need to obey
while driving a car, when people forget those rules they often get
into accidents. Same with programing, there are rules, you can choose
to ignore them, but don't complain when your code is exploited
because your didn't check your input or stopped working when an
namespace you've been mis-using gets taken over by the language.
This would mean classes should be prefixed by extension name...
That is the common case, yes. In fact the date extension's classes
follow this convention to the letter. DateTime + DateTimeZone (Date
is the extension name).Well, almost: DateTime is a date class, not a time class.
Actually it works with both date & time and calling it datedate seems
rather silly. I am not going to waste more time arguing about
DateTime, this has already been covered numerous time, if you got
time to waste go read internals archives.
However, for native classes there maybe exceptions to simplify usage,
when a need for such exceptions arise this will be discussed on
this list.We're only talking about native classes anyway. And I think not
bending the rules simplify usage more than saving a couple of
letters. Wasn't that a lesson we learned from functions?
That's your opinion and you are certainly entitled to it, but that's
just it, your opinion.
Ilia Alshanetsky
Ilia Alshanetsky wrote:
And your point is what? There are even more rules you need to obey while
My point is: Fewer rules make things easier to learn and use.
Well, almost: DateTime is a date class, not a time class.
Actually it works with both date & time and calling it datedate seems
rather silly. I am not going to waste more time arguing about DateTime,
this has already been covered numerous time, if you got time to waste go
read internals archives.
It wasn't me who brought DateTime back into the discussion ;-)
We're only talking about native classes anyway. And I think not
bending the rules simplify usage more than saving a couple of letters.
Wasn't that a lesson we learned from functions?That's your opinion and you are certainly entitled to it, but that's
just it, your opinion.
Thanks for finally acknowledging it. I never said it is anything more.
Stop feeling offended because we have differing opinions, please,
- Chris
Christian Schneider wrote:
Well, almost: DateTime is a date class, not a time class.
Surely it handles both. A DateTime class encapsulates both date and
time information. Just look at the methods like setTime() and the
properties that it contains. I don't think it is badly named at all.
-Rasmus
Ilia Alshanetsky wrote:
Ilia Alshanetsky wrote:
Avoid common namespaces and you'll make your application
futureproof.I'm still wary of this approach because it puts the burden on 99%
of the code to be written (applications) instead of a small,
controllable subset (core and libraries).
Translation: blame other people...I'm not sure what you mean here. I was just doing a head count on
who has to come up with save names: A few core developers or all of
the PHP users.
When we were picking a name the discussion was public on this very
list and based on our analysis of what names people were using in
their application and what would be an ideal name DateTime was
picked. Google's code search confirms we've made the right decision
as it would seem there are only about 8 results for applications
already misusing that namespace.
s more popular and as such needs of many outweigh needs of the few.
A little thought experiment: Let's assume the number of application
classes (and the usage of those classes) is on average higher than
those of the core classes. Would that change the situation?
The number of current users does not matter, simply because are you
not comparing equivalent things here. You are comparing existing code
to something that just came out.
You can use old PHP too, or modify the source code, it is "open
source" after-all.Come on, that can't be the solution. Think about hosting companies
for example.
They as a rule use old versions, in fact I bet you'd be hard pressed
to find a big or even a medium size hosting company offering PHP 5.2
just now. So you have plenty of time to fix your code.
Ilia Alshanetsky
( This should have been to the pigging list !!!! sorry Ilia )
Ilia Alshanetsky wrote:
You can use old PHP too, or modify the source code, it is "open
source" after-all.Come on, that can't be the solution. Think about hosting companies for
example.They as a rule use old versions, in fact I bet you'd be hard pressed to
find a big or even a medium size hosting company offering PHP 5.2 just
now. So you have plenty of time to fix your code.
The main problem here Ilia is that people HAVE to fix their code JUST IN
CASE the host updates. Some people will not even know they have a
problem because they are using a third party application and then they
will not know how to fix it IF their host updates.
Since it would seem that most hosts have not even switched to PHP5
anyway, this is probably all academic anyway, but we have been here
before, with versions of PHP released that broke a large number of
applications and it got to the state that host WOULD NOT update in case
it broke something.
DateTime is just another example of the fact that PHP has no management
of conventions and these get changed version to version. We NEED a
mechanism to pinch back common function names that does not break
existing applications simply because the vast number of users have no
knowledge that there is a problem!
--
Lester Caine - G8HFL
L.S.Caine Electronic Services - http://home.lsces.co.uk
Model Engineers Digital Workshop -
http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/
Treasurer - Firebird Foundation Inc. - http://www.firebirdsql.org/index.php
Hello Lester,
we have the same problem for functions since years, why is there suddenly
such a big problem with classes now? All new php/pecl classes will follow
one of the following rules:
- Prefix with the extension name
- Postfix with "Iterator"
- Postfix with "Exception"
that seems the same amount of protection as prefix functions with extension
name plus underscore. I don't see any problem since the above rule is in
place.
best regards
marcus
Sunday, November 5, 2006, 6:09:54 PM, you wrote:
( This should have been to the pigging list !!!! sorry Ilia )
Ilia Alshanetsky wrote:
You can use old PHP too, or modify the source code, it is "open
source" after-all.Come on, that can't be the solution. Think about hosting companies for
example.They as a rule use old versions, in fact I bet you'd be hard pressed to
find a big or even a medium size hosting company offering PHP 5.2 just
now. So you have plenty of time to fix your code.
The main problem here Ilia is that people HAVE to fix their code JUST IN
CASE the host updates. Some people will not even know they have a
problem because they are using a third party application and then they
will not know how to fix it IF their host updates.
Since it would seem that most hosts have not even switched to PHP5
anyway, this is probably all academic anyway, but we have been here
before, with versions of PHP released that broke a large number of
applications and it got to the state that host WOULD NOT update in case
it broke something.
DateTime is just another example of the fact that PHP has no management
of conventions and these get changed version to version. We NEED a
mechanism to pinch back common function names that does not break
existing applications simply because the vast number of users have no
knowledge that there is a problem!
--
Lester Caine - G8HFLL.S.Caine Electronic Services - http://home.lsces.co.uk
Model Engineers Digital Workshop -
http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/
Treasurer - Firebird Foundation Inc. - http://www.firebirdsql.org/index.php
Best regards,
Marcus
Hello Marcus, hello Ilia,
now you two got me confused:
Marcus Boerger wrote:
we have the same problem for functions since years, why is there suddenly
such a big problem with classes now? All new php/pecl classes will follow
one of the following rules:
- Prefix with the extension name
- Postfix with "Iterator"
- Postfix with "Exception"
that seems the same amount of protection as prefix functions with extension
name plus underscore. I don't see any problem since the above rule is in
place.
This would mean classes should be prefixed by extension name...
Ilia Alshanetsky wrote:
The classes/functions/constants that will be added in the future will
be based largely on the names the developers of said language
components decide upon. In the event their names present issues, such
as BC breaks there would be a review done to determine the merits of
keeping or changing the name. It is really quite simple.
... or not?
- Chris
Hello Marcus, hello Ilia,
now you two got me confused:Marcus Boerger wrote:
we have the same problem for functions since years, why is there
suddenly
such a big problem with classes now? All new php/pecl classes will
follow
one of the following rules:
- Prefix with the extension name
- Postfix with "Iterator"
- Postfix with "Exception"
that seems the same amount of protection as prefix functions with
extension
name plus underscore. I don't see any problem since the above rule
is in
place.This would mean classes should be prefixed by extension name...
That is the common case, yes. In fact the date extension's classes
follow this convention to the letter.
DateTime + DateTimeZone (Date is the extension name).
However, for native classes there maybe exceptions to simplify usage,
when a need for such exceptions arise this will be discussed on this
list.
Ilia Alshanetsky
Ilia Alshanetsky wrote:
When we were picking a name the discussion was public on this very list
and based on our analysis of what names people were using in their
application and what would be an ideal name DateTime was picked.
I'm not questioning this decision. I'm talking about the policy for
further classes. Maybe I should change the topic to be clearer...
A little thought experiment: Let's assume the number of application
classes (and the usage of those classes) is on average higher than
those of the core classes. Would that change the situation?The number of current users does not matter, simply because are you not
comparing equivalent things here. You are comparing existing code to
something that just came out.
Forget about all the code out there: Let's say the average application
uses its own classes 10 times and PHP core classes only 5 times, which
one should have the right to the short and more convenient name?
And I'm not saying that this is the case, it's just a thought.
Come on, that can't be the solution. Think about hosting companies for
example.They as a rule use old versions, in fact I bet you'd be hard pressed to
find a big or even a medium size hosting company offering PHP 5.2 just
now. So you have plenty of time to fix your code.
I could be mean and ask why that is. But that's not the discussion here.
We're talking about the naming policy of classes in the long run.
Again: I'm not asking to change anything, I'm just mentioning that there
are different point of views (PHP core centric vs. application centric
ones) which both have to be recognized.
- Chris
Ilia Alshanetsky wrote:
When we were picking a name the discussion was public on this very
list and based on our analysis of what names people were using in
their application and what would be an ideal name DateTime was
picked.I'm not questioning this decision. I'm talking about the policy for
further classes. Maybe I should change the topic to be clearer...
We've already established a sufficiently clear policy on this matter.
When someone adds a feature to a language which is anticipated to
cause BC breaks its merits are discussed on the list where all sides
get a chance to expression their opinion. Once that's done developers
do a quick vote and based on this vote decision is made. This is a
fairly clear, simple and transparent process.
A little thought experiment: Let's assume the number of
application classes (and the usage of those classes) is on
average higher than those of the core classes. Would that change
the situation?
The number of current users does not matter, simply because are
you not comparing equivalent things here. You are comparing
existing code to something that just came out.Forget about all the code out there: Let's say the average
application uses its own classes 10 times and PHP core classes only
5 times, which one should have the right to the short and more
convenient name?
The language always has the best pick of namespaces, this is not just
PHP, but ANY language. The fact we've made a compromise and allows
PEAR to retain the date class IMO has been a horrible mistake, one
hopefully not to be repeated in the future.
And I'm not saying that this is the case, it's just a thought.
Come on, that can't be the solution. Think about hosting
companies for example.
They as a rule use old versions, in fact I bet you'd be hard
pressed to find a big or even a medium size hosting company
offering PHP 5.2 just now. So you have plenty of time to fix your
code.I could be mean and ask why that is. But that's not the discussion
here. We're talking about the naming policy of classes in the long
run.
The classes/functions/constants that will be added in the future will
be based largely on the names the developers of said language
components decide upon. In the event their names present issues, such
as BC breaks there would be a review done to determine the merits of
keeping or changing the name. It is really quite simple.
Ilia Alshanetsky
Ilia Alshanetsky wrote:
The language always has the best pick of namespaces, this is not just
PHP, but ANY language. The fact we've made a compromise and allows PEAR
to retain the date class IMO has been a horrible mistake, one hopefully
not to be repeated in the future.
I never used the PEAR Date - it was crap - but all my applications
failed with your new one BECAUSE Date was the obvious name for that
package. I STILL can not see why we can't just select these things as I
do in C++ and include your new function if I want or keep with my own
established version - what ever the name. This new stuff does not HAVE
to be hard coded into the core - simply loadable like any other good
extensible language? If we don't want it we don't load it! I don't need
any database stuff other than Firebird - therefore I want a DATE and
TIME package that follows Firebird rules end of story.
--
Lester Caine - G8HFL
L.S.Caine Electronic Services - http://home.lsces.co.uk
Model Engineers Digital Workshop -
http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/
Treasurer - Firebird Foundation Inc. - http://www.firebirdsql.org/index.php
Hello,
Ilia Alshanetsky wrote:
The language always has the best pick of namespaces, this is not just
PHP, but ANY language. The fact we've made a compromise and allows PEAR
to retain the date class IMO has been a horrible mistake, one hopefully
not to be repeated in the future.
For the 10^347 times, the problem was/is not Date but the way global
namespace and features got in late in the game, without previous
warning in any previous PHP release or any announcements.
The problem is that we just considered that we can do it whenever we
want and how we want, that is the horrible mistake.
Things are however getting better, at least for a limited amount of
developers who have to justify/explain/change the names they use in
their extensions. It will be perfect if this rule applies to anyone
and the naming decisions are done before the extension/addition is in
a release (RC or final).
--Pierre
Ilia Alshanetsky wrote:
The language always has the best pick of namespaces, this is not
just PHP, but ANY language. The fact we've made a compromise and
allows PEAR to retain the date class IMO has been a horrible
mistake, one hopefully not to be repeated in the future.I never used the PEAR Date - it was crap - but all my applications
failed with your new one BECAUSE Date was the obvious name for that
package. I STILL can not see why we can't just select these things
as I do in C++ and include your new function if I want or keep with
my own established version - what ever the name. This new stuff
does not HAVE to be hard coded into the core - simply loadable like
any other good extensible language? If we don't want it we don't
load it! I don't need any database stuff other than Firebird -
therefore I want a DATE and TIME package that follows Firebird
rules end of story.
You seem to be under the assumption that people care about what it is
that you want, reality is that most people could care less. That said
this is an open source project, so rather then pointless whining on
the list you can always tweak the source code to your needs, such is
the beauty of the open source software.
Ilia Alshanetsky
Ilia Alshanetsky wrote:
Ilia Alshanetsky wrote:
The language always has the best pick of namespaces, this is not just
PHP, but ANY language. The fact we've made a compromise and allows
PEAR to retain the date class IMO has been a horrible mistake, one
hopefully not to be repeated in the future.I never used the PEAR Date - it was crap - but all my applications
failed with your new one BECAUSE Date was the obvious name for that
package. I STILL can not see why we can't just select these things as
I do in C++ and include your new function if I want or keep with my
own established version - what ever the name. This new stuff does not
HAVE to be hard coded into the core - simply loadable like any other
good extensible language? If we don't want it we don't load it! I
don't need any database stuff other than Firebird - therefore I want a
DATE and TIME package that follows Firebird rules end of story.You seem to be under the assumption that people care about what it is
that you want, reality is that most people could care less. That said
this is an open source project, so rather then pointless whining on the
list you can always tweak the source code to your needs, such is the
beauty of the open source software.
Then perhaps it is about time that we cut a version of PHP that does
what users want rather than a few developers :)
The whole point here is that ISP's install this stuff so we have to work
with the version that ISP's install. We have had a number of major
crap-up's caused by making non-compatible changes and most of the time
all that was needed was a simple switch to enable that new code IF it
was needed. YOU should care that people want to use PHP or perhaps you
are more of a mind to take the Microsoft attitude - sod the 'cuctomers'
we will do what we want! But then Microsoft are now getting involved so
perhaps that's to be expected ;)
Personally I'm more than happy with PHP 5.0.4 and that is what is in MY
customer sites, but other suppliers are upgrading when THEY want to, and
so I then have to go round and make sure all MY code still works. I
was lead to believe that the next BC break would come with PHP6 - but
then you can't trust people no to change the rules when they feel like
it :(
--
Lester Caine - G8HFL
L.S.Caine Electronic Services - http://home.lsces.co.uk
Model Engineers Digital Workshop -
http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/
Treasurer - Firebird Foundation Inc. - http://www.firebirdsql.org/index.php
It seems like the history of every language goes through this...
Some solve it cleanly, from the beginning with a Documented Feature:
If I had a time machine, way more brains and C skill, and could waylay
Rasmus back in 1995/1996, you'd have something like:
The PHP_* name space is reserved for Core PHP Features.
Then everybody would know that the internal PHP Date object was gonna
be PHP_Date, and nobody would be dumb enough to use that in their app.
code, and if they were dumb enough, you'd point to the docs.
As it stands now, you'd almost want to MD5() all your class names in a
code generation phase, just to be safe :-v
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?