But the longer you wait, the more you're likely to run into implementation
problems.
I think what you meant to say was, 'the longer you wait, the more likely you
foresee the implementation problems'.
I don't know how many users you have. I'm not going to pretend I know how
many users PHP has
>It's a bit ironic that you underestimate PHP's devs with that sort of
>assumption, don't you think?
I do not underestimate anyone.
I just meant that those who will find class visibility "complex" may not use
namespaces at all.
But those who write a full OO code may want full OO features. Not OO t
Just wanted to say that this is the third such commit I've seen go by
in the last couple of days.
If it's not too late, I would suggest that the change to put static
into the macro be reverted because it is causing needless changes to
fan out into other modules.
Additionally, it is also
Hi Franck,
we agreed long ago on a very easy scheme, there shall only be is-a and
public classes.
Do you really think it makes the scheme "easier" to allow for public
classes
only?
Well, yes, actually.
Class visibility is a common OO concept, that improves the encapsulation
of the code,
2008/10/30 Franck Jasper <[EMAIL PROTECTED]>:
> A recurrent scheme, on internals, is to underestimate the PHP developer's
> skills
> and needs.
> And no namespaces were added to the language by that time, because it was
> probably considered that a "PHP developer" would never need such a thing...
Hi,
[For conclusive proposal, see below.]
>> 1) Internal FPU precision on x86.
>
> Do you have any test cases show the error?
Sure. Consider the following C code:
#include
int main (int argc, char **argv) {
volatile double v = 100.0;
printf ("%.35f\n%.35f\n", 0.002877, 2877.0 / v);
>Hello Ron,
>
> we agreed long ago on a very easy scheme, there shall only be is-a and
>public classes.
Do you really think it makes the scheme "easier" to allow for public classes
only?
Class visibility is a common OO concept, that improves the encapsulation
of the code, and which, I'm afraid of
Hi Stefan,
>> 1) Define some macros for math-related functions that will ensure the
>> function itself always uses double precision. Add configure checks for
>> these macros.
>
> Do you know what the rationale behind the standard compiler behaviour is?
> Because trying to outsmart the compiler i
Hi Lukas, Hi Scott,
> Scott said he could apply the patch for you. And he is sitting right in
> front of me ..
Actually, since I've stirred up the list a bit just now, I'd like to
wait until we have consensus on this issue.
But thanks for the offer. :-)
Regards,
Christian
--
PHP Internals - P
On 30-Oct-08, at 5:55 AM, Christian Seiler wrote:
1) Internal FPU precision on x86.
Do you have any test cases show the error?
2) Specification problem (which rounding mode should actually be
used?)
3) Dividing/multiplying by >= 10^23 is not exact.
4) round (1.255, 2) should give 1.26 bu
Hi.
Stan Vassilev | FM wrote:
I suggest we introduce a new construct which will return a string
when passed any identifier to resolve against the current file's use
clauses:
nameof Symbol\Name;
...
NOTE: As a side effect this means less direct writing of string
function/class names, and less
Hello Christian,
Thursday, October 30, 2008, 10:55:48 AM, you wrote:
> Hi,
>> Modified files: (Branch: PHP_5_3)
>> /php-src/ext/standard math.c
>> Log:
>> Fixed bug #42294 (Unified solution for round() based on C99 round)
>> [DOC] New implementation of round() to wo
Hi,
Scott said he could apply the patch for you. And he is sitting right
in front of me ..
regards,
Lukas
On 28.10.2008, at 18:28, Christian Seiler wrote:
Hi,
Sounds to me like you have done your homework and are committed to
maintaining this. Codewise I will leave the decision to Johann
Hi,
> Modified files: (Branch: PHP_5_3)
> /php-src/ext/standard math.c
> Log:
> Fixed bug #42294 (Unified solution for round() based on C99 round)
> [DOC] New implementation of round() to work-around inconsistencies for win32
> and 64 bit platforms.
>
> This so
On 10/29/08, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
> Just a quick reminder for all of the developers, RC3 (the final RC)
> will be tagged tomorrow afternoon (EST) time, please try to get
> whatever patches (bug fixes only, please) you still want into it. If
> there are reasons to delay, criti
Hi Illia,
Am Mittwoch, den 29.10.2008, 17:02 -0400 schrieb Ilia Alshanetsky:
[...]
> Your patch with slight revisions just went in.
The sad thing is, that the patch just fixes half of the issue. If your
try the examples in the bugreport, most of the still work. We have also
check the msgids for o
Derick,
I have raised bug
Refer http://bugs.php.net/bug.php?id=46417
Tests related to getdate including test case for the above bug is available at
http://www.4shared.com/file/68976901/6ce81c88/getdate.html.
Please have a look at the tests and use following tests for above bug
PHP53/getda
17 matches
Mail list logo
