Hi,
that's the commonly used (and existing) "Feedback" status, but often
this won't lead to the required feedback.
johannes
On Fri, 2006-11-17 at 08:38 +0100, Ron Korving wrote:
> Why not add another bug-status called "incomplete" or something, and append
> a standard message saying "Please stu
Majority of the "bogus" bugs are truly bogus, I see no reason to
change a perfectly valid term used to describe bugs.
On 17-Nov-06, at 2:38 AM, Ron Korving wrote:
Why not add another bug-status called "incomplete" or something,
and append
a standard message saying "Please study the bug-repo
Why not add another bug-status called "incomplete" or something, and append
a standard message saying "Please study the bug-reporting guidelines in
order to write complete and accurate bug reports."? I think this tiny
addition to tagging something "bogus" would make a lot of bug reporters
happi
Richard Lynch wrote:
> On Sat, November 11, 2006 7:37 am, Rasmus Lerdorf wrote:
>> helping to get rid of bogus reports or translating the really bad
>> reports into a simple reproducable test case is often the part that
>
> This is a plea for not being quite so bogus-trigger-happy as we have
> in
On Sat, November 11, 2006 7:37 am, Rasmus Lerdorf wrote:
> helping to get rid of bogus reports or translating the really bad
> reports into a simple reproducable test case is often the part that
This is a plea for not being quite so bogus-trigger-happy as we have
in the past.
Many correct, if inc
On Fri, November 10, 2006 12:19 pm, Sean Coates wrote:
> of PHP applications that are developed for internal use. I don't know
> of
> anyone currently using PHP 4 to develop new PHP apps unless they're
> for
> external distribution.
Are you living in a bubble? :-) :-) :-)
There's a zillion ISPs t
On Fri, November 10, 2006 10:51 am, Sean Coates wrote:
+1
Given the usage of \ for string escaping, I'd have to vote for :::, I
guess...
But it wouldn't kill me if \ won the vote either.
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
On Fri, 10 Nov 2006, Hans Lellelid wrote:
>
> >> I think there is far more
> >> demand for a fast & stable PHP then for syntatic sugar features which
> >> seem extremely useful, but in the end prove to carry too much baggage.
> >>
> >
> > Nothing has been proven either way.. at least not pub
Sean,
I think there are fair chances we'll introduce a very simplistic
namespaces capability in PHP 6. It's pretty clear it will not have
the notion of imports, and will be very much focused on classes (as
opposed to functions and variables). In fact, I think you can very
much imagine them
Am 10.11.2006 um 19:47 schrieb Hans Lellelid:
I think there is far more
demand for a fast & stable PHP then for syntatic sugar features
which
seem extremely useful, but in the end prove to carry too much
baggage.
Nothing has been proven either way.. at least not publicly.. unless I
jus
Am 11.11.2006 um 14:37 schrieb Rasmus Lerdorf:
I am not sure why this thread was revived. We decided long ago
that we
would have namespaces in PHP 6 barring any nasty technical problems
and
assuming a good way to implement it could be found.
I'm not sure if that was made clear. The meeting
What? I suppose if you always want to name your latest class
foobar, then yes, but then you have other problems... If you
properly pick a classname you almost never need to rename it let
alone the methods contained with the class. Plus namespaces are
going to introduce their own sets of pro
I am not sure why this thread was revived. We decided long ago that we
would have namespaces in PHP 6 barring any nasty technical problems and
assuming a good way to implement it could be found.
And I'll second Tony here and mention that we really could use more
eyeballs on the bug database. I a
Zitat von Hans Lellelid <[EMAIL PROTECTED]>:
I think there is far more
demand for a fast & stable PHP then for syntatic sugar features which
seem extremely useful, but in the end prove to carry too much baggage.
Nothing has been proven either way.. at least not publicly.. unless I
just miss
On Sat, 2006-11-11 at 00:31 +0100, Marcus Boerger wrote:
> Hello Hans,
>
> Friday, November 10, 2006, 8:30:55 PM, you wrote:
>
> > Brian Moon wrote:
> >>> Unfortunately namespaces are not only syntactic sugar, but dire
> >>> necessity
> >>> for PHP if it wants to be taken as a serious langauage a
Hello Hans,
Friday, November 10, 2006, 8:30:55 PM, you wrote:
> Brian Moon wrote:
>>> Unfortunately namespaces are not only syntactic sugar, but dire
>>> necessity
>>> for PHP if it wants to be taken as a serious langauage and defend it's
>>> position against other arising 'web scripting' alterna
Hello Sebastian,
the best ones unfortunatley are GPL and thus not acceptable. I once
played with case insensitive hashes. They worked very much faster -
but they had more conflicts. If we were about intel processors my
experience is that string functions can be optimized at assembler level
very
Tony Bibbs wrote:
While I could munge the class names in one or more packages as you
suggest then I'm in maintainability hell because when I need to update
one of the other packages (for security, features or bugfixes) you have
to do the name munging again.
C'mon, that ain't right. Next excu
Ilia Alshanetsky wrote:
If you properly pick a
classname you almost never need to rename it let alone the methods
contained with the class. Plus namespaces are going to introduce their
own sets of problems where extension X adds namespace X, which some lib
already decided to use and we are b
On 10-Nov-06, at 5:01 PM, Lukas Kahwe Smith wrote:
Remember the point Sebastian made earlier. Its also a hassle during
development of the library code itself, where you have to deal with
endlessly long class names.
You still have the same long names, you've just split them into two
namesp
On 10-Nov-06, at 4:57 PM, Tony Bibbs wrote:
While I could munge the class names in one or more packages as you
suggest then I'm in maintainability hell because when I need to
update one of the other packages (for security, features or
bugfixes) you have to do the name munging again.
What
Patrick Mueller wrote:
There would typically be a one time 'hit' in your code for a long,
prefixed named used as a constructor, or possibly a static method called
on a factory. After that, if you're dealing with object instances, then
instead of function names (which would need to also use a
While I could munge the class names in one or more packages as you
suggest then I'm in maintainability hell because when I need to update
one of the other packages (for security, features or bugfixes) you have
to do the name munging again.
C'mon, that ain't right. Next excuse?
--Tony
Patric
Daniel T. Gorski wrote:
Escpecially due to the new OO features of PHP 5, namespaces are urgently
required for writers of independent libraries which should not clash.
I would claim exactly the opposite.
That's because you already get scoping on names, for free, when you use
objects. The meth
Brian Moon wrote:
>> Unfortunately namespaces are not only syntactic sugar, but dire
>> necessity
>> for PHP if it wants to be taken as a serious langauage and defend it's
>> position against other arising 'web scripting' alternatives.
>
> It seems the list of things that PHP needs to be "taken as
Unfortunately namespaces are not only syntactic sugar, but dire necessity
for PHP if it wants to be taken as a serious langauage and defend it's
position against other arising 'web scripting' alternatives.
It seems the list of things that PHP needs to be "taken as a serious
langauage" is never
>> I think there is far more
>> demand for a fast & stable PHP then for syntatic sugar features which
>> seem extremely useful, but in the end prove to carry too much baggage.
>>
>
> Nothing has been proven either way.. at least not publicly.. unless I
> just missed it.
>
I haven't talked
On 10-Nov-06, at 1:19 PM, Sean Coates wrote:
PHP 6 is not yet out and probably won't be production quality for
quite
some time. Which means that migration to it en mass is probably not
going to happen this decade :-).
I'm not talking about forcing everyone to use namespaces tomorrow. I'm
t
On 10 Nov 13:05, Ilia Alshanetsky wrote:
> On 10-Nov-06, at 12:41 PM, Sean Coates wrote:
>> [...]
>> I also don't deny that there will be a minor performance hit. There are a
>> ton of other things in PHP that reduce performance.. the idea is to find
>> a balance of which ones are worth it (as w
Ilia Alshanetsky wrote:
> As your key size increases the slower the key hash generation process
> becomes, if you look at the PHP's hash key generation code you'll see
> that it works best for 8 or less chars, anything longer and the
> performance starts to drop.
It's been a long time since I stu
> PHP 6 is not yet out and probably won't be production quality for quite
> some time. Which means that migration to it en mass is probably not
> going to happen this decade :-).
I'm not talking about forcing everyone to use namespaces tomorrow. I'm
trying to plan for a future where there's a sen
On 10-Nov-06, at 12:54 PM, Sebastian Bergmann wrote:
Ilia Alshanetsky wrote:
If anything it'll make code complex and intertwined, introduce
serious
scope issue most people have not had to consider up until now and so
on. It will without a doubt increase language complexity as well,
which
On 10-Nov-06, at 12:41 PM, Sean Coates wrote:
I don't think namespaces are a magic bullet. As it stands, it's
impossible to use namespaces without a third party patch that may
or may
not work. I strongly believe that if namespaces are implemented in PHP
6, most of our prefixing/symbol collis
Ilia Alshanetsky wrote:
> If anything it'll make code complex and intertwined, introduce serious
> scope issue most people have not had to consider up until now and so
> on. It will without a doubt increase language complexity as well, which
> generally translates to a loss in performance.
Am I r
CTED]
> Sent: Friday, November 10, 2006 8:51 AM
> To: internals
> Subject: [PHP-DEV] Namespaces in PHP 6 - ++$take
>
> Hello all,
>
> A number of factors have come together to prompt me to
> possibly commit mailing-list-suicide by re-opening the
> namespace i
> That's a bit of a circular logic no? There are indeed technical
> challenges to implementing namespaces, these reasons have been covered
> in previous discussions many times, since no adequate solution was
> devised they were never implemented. Once those issues are resolved or
> at the very leas
On 10-Nov-06, at 11:51 AM, Sean Coates wrote:
The way I see it is that implementing namespaces is a technical
hurdle,
and the reasons we haven't jumped it are political, not technical.
That's a bit of a circular logic no? There are indeed technical
challenges to implementing namespaces, t
Hello all,
A number of factors have come together to prompt me to possibly commit
mailing-list-suicide by re-opening the namespace issue.
Last week at Zendcon, a number of PHP developers/community members
chatted about namespaces in PHP 6. That chat was the prime motivator for
this email, but the
38 matches
Mail list logo
