Welcome! Log In Create A New Profile

Advanced

[PHP-DEV] Re: My rounding proposal: Ok for PHP 5.3?

Posted by Lukas Kahwe Smith 
Lukas Kahwe Smith
[PHP-DEV] Re: My rounding proposal: Ok for PHP 5.3?
October 30, 2008 12:50PM
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 Johannes
>> however.
>
> As Johannes has given his OK, I've created two patches (one for PHP
> 5.3
> and one for HEAD):
>
> http://www.christian-seiler.de/temp/php/2008-10-28-fpu/php-float-precision-5.3.patch
> http://www.christian-seiler.de/temp/php/2008-10-28-fpu/php-float-precision-6.patch
> (Both are basically identical)
>
> I've tested them with the current PHP 5.3 branch under Linux and
> Windows
> (gcc) and with current PHP 5.3 under Windows (MSVC8, i.e. 2005)
>
> The patch does the following:
>
> * New zend_float.h which defines the following macros:
> ZEND_FLOAT_DECLARE() - Declare necessary helper vars
> ZEND_FLOAT_ENSURE() - Ensure double precision
> ZEND_FLOAT_RESTORE() - Restore previous precision
> ZEND_FLOAT_RETURN(val) - Return a double and restore prev. prec.
> (They are an alias to corresponding the XPFPA macros from my header
> file)
>
> * Added my configure checks to acinclude.m4.
>
> * Use them in zend_strtod.c and zend_operators.c in order to ensure
> that the precision used for calculations and string-to-float
> conversions is always double precision.
>
> * Added Zend/tests/float_prec_001.phpt which makes sure that both
> calculations and string-to-float logic use double precision.
> [This will also detect misbehaving platforms.]
>
> Please feel free to change any comments wrt. where this logic is from
> and/or whitespace formatting in the files.
>
> I'd appreciate it if you could commit this patch in the next days so I
> can commit my patch for round() that relies on the above.
>
> Regards,
> Christian

Lukas Kahwe Smith
mls@pooteeweet.org




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Christian Seiler
Re: [PHP-DEV] Re: My rounding proposal: Ok for PHP 5.3?
October 30, 2008 03:40PM
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 - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Franck Jasper
Re: [PHP-DEV] Re: Class visibility in namespaces
October 30, 2008 04:25PM
>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 it, will be requested again in the future,
like typed return values and typed properties.

> we agreed long ago on a very easy scheme
A recurrent scheme, on internals, is to underestimate the PHP developer's skills
and needs.
Not only is this behaviour a bit upsetting for those who want to use PHP
seriously, but in the long run, this may lead to insufficient specifications, or
arguable conception choices.

When PHP5 was designed, it was probably thought that a specific resolution
operator would make it "easier" for a "PHP developer" to distinguish between
static and non-static calls...
and so "::" was introduced, in spite of the fact that "::" is for long a
namespace separator in various languages.

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...
even though namespaces have existed for long in many OO languages.

Franck

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Josh Davis
Re: [PHP-DEV] Re: Class visibility in namespaces
October 30, 2008 05:05PM
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...

It's a bit ironic that you underestimate PHP's devs with that sort of
assumption, don't you think?

If you dig into this list's archives, you'll see that namespaces were
mentionned as a matter of interest as early as 2000(?) and if memory
serves, a previous round of patches in 2005 did include class
visibility (a side effect actually... IIRC). At least, I remember
super-long threads about it and it wasn't pretty. Please don't take my
word for it as I might remember some of it incorrectly.

Anyway, my point is there's huge archives and you may find more
informations about that if you're really interested in it. Also, if
you can unearth some substantial amount of user requests, it will help
your cause and prove that people actually want/need that feature.

-JD

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Steph Fox
Re: [PHP-DEV] Re: Class visibility in namespaces
October 30, 2008 05:05PM
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, and which, I'm afraid of it, will be requested again in the
> future,
> like typed return values and typed properties

Why be afraid of it? At least class visibility is something it's possible to
add at a later stage, should a genuine need for it ever become apparent.

> A recurrent scheme, on internals, is to underestimate the PHP developer's
> skills
> and needs.

Can I sell you a Google toolbar? :-) I promise you it'll be cheap!

> Not only is this behaviour a bit upsetting for those who want to use PHP
> seriously, but in the long run, this may lead to insufficient
> specifications, or
> arguable conception choices.
>
> When PHP5 was designed, it was probably thought that a specific resolution
> operator would make it "easier" for a "PHP developer" to distinguish
> between
> static and non-static calls...
> and so "::" was introduced, in spite of the fact that "::" is for long a
> namespace separator in various languages.

"::" was introduced in PHP 3, not 5. Those 'various languages' you refer to
barely existed at the time.

> 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...
> even though namespaces have existed for long in many OO languages.

The first version of the Zend Engine with namespace support was rolled as a
special edition of PHP 4.3.0 and released on php.net for public testing in
2002. This was originally scheduled for full release in PHP 5.0. (PHP is
not, by the way, 'an OO language' in the sense you use the term.) It
certainly wasn't withdrawn for the reasons you suggest.

- Steph


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sorry, only registered users may post in this forum.

Click here to login