Hi all,
GMP object is object. Therefore, is_scalar()
returns false for GMP
objects.
[yohgaki@dev php-src]$ ./php-bin -r '$v = gmp_init("0");
var_dump(gettype($v));'
string(6) "object"
[yohgaki@dev php-src]$ ./php-bin -r '$v = gmp_init("0");
var_dump(is_scalar($v));'
bool(false)
This is correct behavior, but this behavior is debatable, IMO.
Any comments?
--
Yasuo Ohgaki
yohgaki@ohgaki.net
GMP object is object. Therefore,
is_scalar()
returns false for GMP
objects.[yohgaki@dev php-src]$ ./php-bin -r '$v = gmp_init("0");
var_dump(gettype($v));'
string(6) "object"
[yohgaki@dev php-src]$ ./php-bin -r '$v = gmp_init("0");
var_dump(is_scalar($v));'
bool(false)This is correct behavior, but this behavior is debatable, IMO.
Any comments?
is_numeric()
can be problematic also.
[yohgaki@dev php-src]$ ./php-bin -r '$v = gmp_init("0");
var_dump(is_numeric($v));'
bool(false)
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi all,
GMP object is object. Therefore,
is_scalar()
returns false for GMP
objects.[yohgaki@dev php-src]$ ./php-bin -r '$v = gmp_init("0");
var_dump(gettype($v));'
string(6) "object"
[yohgaki@dev php-src]$ ./php-bin -r '$v = gmp_init("0");
var_dump(is_scalar($v));'
bool(false)This is correct behavior, but this behavior is debatable, IMO.
Any comments?
Sorry, I don't understand what you're saying. Why would is_scalar return
true for an object?
Nikita
Hi all,
GMP object is object. Therefore,
is_scalar()
returns false for GMP
objects.[yohgaki@dev php-src]$ ./php-bin -r '$v = gmp_init("0");
var_dump(gettype($v));'
string(6) "object"
[yohgaki@dev php-src]$ ./php-bin -r '$v = gmp_init("0");
var_dump(is_scalar($v));'
bool(false)This is correct behavior, but this behavior is debatable, IMO.
Any comments?
Sorry, I don't understand what you're saying. Why would is_scalar return
true for an object?
Its not even an object, its a resource.
I think you are completely off path here Yasuo, same with your empty() thread.
That just doesn't make sense.
-Hannes
On Sun, Dec 29, 2013 at 11:26 AM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:
Hi all,
GMP object is object. Therefore,
is_scalar()
returns false for GMP
objects.[yohgaki@dev php-src]$ ./php-bin -r '$v = gmp_init("0");
var_dump(gettype($v));'
string(6) "object"
[yohgaki@dev php-src]$ ./php-bin -r '$v = gmp_init("0");
var_dump(is_scalar($v));'
bool(false)This is correct behavior, but this behavior is debatable, IMO.
Any comments?
Sorry, I don't understand what you're saying. Why would is_scalar return
true for an object?Its not even an object, its a resource.
I think you are completely off path here Yasuo, same with your empty() thread.
That just doesn't make sense.
Waiiit a minute. It is a object in current master?
That will break code that makes sure gmp_init() worked by doing
is_resource()
on the return value.
-Hannes
Hi Nikita,
Sorry, I don't understand what you're saying. Why would is_scalar return
true for an object?
Since GMP object works just like numbers, this could cause bug that
users assume it is "number" or "scalar".
Variables are promoted to GMP object when math operator is applied.
(This is nice, IMO) GMP objects works like number mostly, this can be
cause of bugs in user scripts.
It would be more intuitive for users if GMP object is handled as "number"
IMHO.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi!
Since GMP object works just like numbers, this could cause bug that
users assume it is "number" or "scalar".
is_scalar checks if the value is a scalar. Objects and resources are not
scalars. If someone doesn't understand that, he should read manual page
of is_scalar before using it.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi Stas,
On Tue, Dec 31, 2013 at 5:45 AM, Stas Malyshev smalyshev@sugarcrm.comwrote:
Since GMP object works just like numbers, this could cause bug that
users assume it is "number" or "scalar".is_scalar checks if the value is a scalar. Objects and resources are not
scalars. If someone doesn't understand that, he should read manual page
of is_scalar before using it.
I agree. Generally speaking, users should know this.
I'm bringing up this as issue to discuss, since GMP numbers will be work
like numbers from PHP 5.6. Most users will expect numbers are evaluated
like other numbers(int/float), I suppose.
It may be hard to distinguish normal numbers(int/float) and GMP numbers
in large scripts, too.
I can think of 3 options for now.
- Treat GMP object as special object
- Make scalar object
- Make autoboxing like feature
We have 4th option that leave it as it now, but it wouldn't be user
friendly.
Since this (GMP numbers work like normal numbers) is new feature, we
may choose better option.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi!
Since this (GMP numbers work like normal numbers) is new feature, we
may choose better option.
I think you're taking it way too far. GMP numbers may support some
functions that scalars support, but that does not mean every function -
especially functions with are specifically designed to distinguish
scalars from objects - would do the same thing for them as for scalars.
If you're interested in their "numeric" properties - i.e. adding them,
multiplying them, etc. - fine, they work that way. But if you "pop the
hood" and look inside - no, they should not be scalars inside, because
they are not.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi Stas,
On Tue, Dec 31, 2013 at 6:31 AM, Stas Malyshev smalyshev@sugarcrm.comwrote:
Since this (GMP numbers work like normal numbers) is new feature, we
may choose better option.I think you're taking it way too far. GMP numbers may support some
functions that scalars support, but that does not mean every function -
especially functions with are specifically designed to distinguish
scalars from objects - would do the same thing for them as for scalars.
If you're interested in their "numeric" properties - i.e. adding them,
multiplying them, etc. - fine, they work that way. But if you "pop the
hood" and look inside - no, they should not be scalars inside, because
they are not.
I agree with your opinion in general.
How about to introduce scalar object that is evaluated as scalar?
It would be useful in user land also.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi Stas,
On Tue, Dec 31, 2013 at 6:31 AM, Stas Malyshev smalyshev@sugarcrm.comwrote:
Since this (GMP numbers work like normal numbers) is new feature, we
may choose better option.I think you're taking it way too far. GMP numbers may support some
functions that scalars support, but that does not mean every function -
especially functions with are specifically designed to distinguish
scalars from objects - would do the same thing for them as for scalars.
If you're interested in their "numeric" properties - i.e. adding them,
multiplying them, etc. - fine, they work that way. But if you "pop the
hood" and look inside - no, they should not be scalars inside, because
they are not.I agree with your opinion in general.
How about introduce scalar object that is evaluated as scalar?
It would be useful in user land also.
http://www.php.net/manual/en/language.oop5.magic.php
Something like __toScalar(), may be?
--
Yasuo Ohgaki
yohgaki@ohgaki.net
-----Original Message-----
From: yohgaki@gmail.com [mailto:yohgaki@gmail.com] On Behalf Of Yasuo Ohgaki
Sent: Monday, December 30, 2013 10:46 PM
To: Stas Malyshev
Cc: Nikita Popov; internals@lists.php.net
Subject: Re: [PHP-DEV] GMP object andis_scalar()
Hi Stas,
On Tue, Dec 31, 2013 at 6:31 AM, Stas Malyshev smalyshev@sugarcrm.comwrote:
Since this (GMP numbers work like normal numbers) is new feature, we
may choose better option.I think you're taking it way too far. GMP numbers may support some
functions that scalars support, but that does not mean every function -
especially functions with are specifically designed to distinguish
scalars from objects - would do the same thing for them as for scalars.
If you're interested in their "numeric" properties - i.e. adding them,
multiplying them, etc. - fine, they work that way. But if you "pop the
hood" and look inside - no, they should not be scalars inside, because
they are not.I agree with your opinion in general.
How about introduce scalar object that is evaluated as scalar?
It would be useful in user land also.http://www.php.net/manual/en/language.oop5.magic.php
Something like __toScalar(), may be?
--
Yasuo Ohgaki
yohgaki@ohgaki.net
I think __toScalar is way to wage, what will __toScalar() return? a bool, an int, a float or a string?
Hi Robert,
I think __toScalar is way to wage, what will __toScalar() return? a bool,
an int, a float or a string?
Not all classes should have __toScalar().
Only classes that should be evaluated as scalar should implement this magic
method.
Return values are programmer's choice.
Whatever scalar values may return.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi!
Only classes that should be evaluated as scalar should implement this
magic method.
We already have type convertors. "scalar" is not a type, it's a group of
types. I don't think it makes sense to convert something to an abstract
scalar - it should be specific scalar type.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi Stas,
On Tue, Dec 31, 2013 at 7:03 AM, Stas Malyshev smalyshev@sugarcrm.comwrote:
Only classes that should be evaluated as scalar should implement this
magic method.We already have type convertors. "scalar" is not a type, it's a group of
types. I don't think it makes sense to convert something to an abstract
scalar - it should be specific scalar type.
Should it? PHP is weakly typed language.
I haven't thought well for scalar object yet and has to consider
various cases.
One thing clear to me is users expects GMP numbers behave like
scalar numbers most likely.
Yet another option for PHP 5.6 is to note GMP numbers as
EXPERIMENTAL.
There are many issues to resolve. IMHO.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi!
Should it? PHP is weakly typed language.
That doesn't mean types do not exist. That means values can be converted
from type to type, but there's no type "scalar" - it is just a group
name of a set of types.
One thing clear to me is users expects GMP numbers behave like
scalar numbers most likely.
I don't think users expect anything like that, I don't see legitimate
use case why users would expect is_scalar return true on GMP object. If
the user is advanced enough to use is_scalar he should understand what
that function does. Or user some other function that is more fit for
their goals.
Yet another option for PHP 5.6 is to note GMP numbers as
EXPERIMENTAL.
GMP is in PHP for a long time, why would it suddenly become experimental?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi Stas,
On Tue, Dec 31, 2013 at 7:20 AM, Stas Malyshev smalyshev@sugarcrm.comwrote:
Should it? PHP is weakly typed language.
That doesn't mean types do not exist. That means values can be converted
from type to type, but there's no type "scalar" - it is just a group
name of a set of types.
Agreed on that scalar is name of types which has single value.
One thing clear to me is users expects GMP numbers behave like
scalar numbers most likely.
I don't think users expect anything like that, I don't see legitimate
use case why users would expect is_scalar return true on GMP object. If
the user is advanced enough to use is_scalar he should understand what
that function does. Or user some other function that is more fit for
their goals.
I agree users who know PHP and GMP well would not expect GMP object
is to evaluated as scalar.
I suppose average users would expect/want GMP number as PHP
number also.
Yet another option for PHP 5.6 is to note GMP numbers as
EXPERIMENTAL.
GMP is in PHP for a long time, why would it suddenly become experimental?
Sorry, I meant GMP number arithmetic with normal operators/math functions/
type evaluation functions is better to be considered as EXPERIMENTAL.
It lacks GMP float support and many function won't work as it should be.
(If we consider GMP number as "number" in PHP)
It's safe to note GMP number arithmetic as EXPERIMENTAL and
resolve issues. IMHO.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net