Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77392
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <541DBCF1.7070206@pascal-martin.fr>
References: <B08F027B-EACA-42A1-BAFD-8B0FB3135016@ajf.me>
	<541DBCF1.7070206@pascal-martin.fr>
Date: Sat, 20 Sep 2014 15:42:56 -0400
Message-ID: <CA+sv8zCcKsLKJDFJCGr3OS9GrrM_RacFjLwKid=DOjMQpV5F5A@mail.gmail.com>
To: Pascal MARTIN <mailing@pascal-martin.fr>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1134b1629ec5d30503846cae
Subject: Re: [PHP-DEV] [VOTE][RFC] Integer Semantics
From: jrbasso@gmail.com (Juan Basso)

--001a1134b1629ec5d30503846cae
Content-Type: text/plain; charset=UTF-8

Why don't you throw an exception instead of returning random things that
are not accurate?

It makes the response of the operation or casts more realistic, since you
will never get INF or NAN as result and possibly transform it to 0
unconsciously. It will keep the semantic for expected types, for example, a
division of 2 integers can result in a integer or float, but never boolean.

Exceptions are there since PHP 5 and it is largely used by frameworks and
developers. It is not a new or not used concept. I guess using them bring
more value to the language than keeping the "lets define a default value
for this case and worry about the other cases later". It just adds more
confusion to developers to know if certain things returns 0, false, -1, etc
for all different functions/operations across the language.


Juan Basso

--001a1134b1629ec5d30503846cae--