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 C
Ilia Alshanetsky wrote:
On 5-Nov-06, at 6:30 PM, Lester Caine 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
On 5-Nov-06, at 6:30 PM, Lester Caine 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 t
Hello,
On 11/6/06, Lester Caine <[EMAIL PROTECTED]> 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 ho
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 PEA
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.
-Ras
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
rat
On 5-Nov-06, at 1:32 PM, Christian Schneider wrote:
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 w
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
On 5-Nov-06, at 1:13 PM, Christian Schneider wrote:
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
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
- Postfi
On 5-Nov-06, at 12:59 PM, Christian Schneider wrote:
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
Ilia Alshanetsky wrote:
On 4-Nov-06, at 11:55 PM, Christian Schneider wrote:
But my favourite solution would be to
a) have namespaces handling this issue
Not happening in 5.2 branch.
I know. I'm talking about a long term solution.
b) not introducing (many) more core classes before that
On 5-Nov-06, at 12:48 PM, Christian Schneider wrote:
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
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
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 f
( 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
On 4-Nov-06, at 11:55 PM, Christian Schneider wrote:
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
On 4-Nov-06, at 11:21 PM, Christian Schneider wrote:
Ilia Alshanetsky wrote:
On 4-Nov-06, at 11:18 AM, Christian Schneider 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%
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 al
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, wi
This one time, at band camp, Christian Schneider <[EMAIL PROTECTED]> 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
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 furt
Hello Christian,
Sunday, November 5, 2006, 5:21:24 AM, you wrote:
> Ilia Alshanetsky wrote:
>> On 4-Nov-06, at 11:18 AM, Christian Schneider wrote:
>>> Ilia Alshanetsky wrote:
>> The language should ALWAYS have the best names possible to simplify
>> development, because that means convenience for
Ilia Alshanetsky wrote:
On 4-Nov-06, at 11:18 AM, Christian Schneider 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 s
On 4-Nov-06, at 11:18 AM, Christian Schneider 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 s
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 distribute
On 3-Nov-06, at 3:01 PM, 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). I'm wondering if there's
any
chance
to add an ini directive in order to disable the definition of the
new
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 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
30 matches
Mail list logo
