Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:49308
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.42 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type;
        b=x2TP9D9whDiw/yXjGLGw8AzSdg0RrWAwA9F4zh0uQsQ8rASrNTNz6syGlhdOmQxz4j
         DaTtoYlb4VssC/H9X4KXCS6256yqUcRBkwuh5s48CjAvMsXtJdfGgB+lFRAIENIEWUWO
         FFJGpMtO8z3x3wSTsbtRASDgDiadN33wIbDu4=
MIME-Version: 1.0
In-Reply-To: <4C61F3EF.5030409@sugarcrm.com>
References: <AANLkTim7sNwZWyo8dQz-o6S=Tta-OGYqnDM0cDJX3A49@mail.gmail.com>
	<1281478269.6608.292.camel@guybrush>
	<alpine.DEB.2.00.1008102325440.29410@kossu.derickrethans.nl>
	<AANLkTikaMfPERRH8bKqBj1ajf8muBrnQK_Gv6SZcObzK@mail.gmail.com>
	<AANLkTi=OebDc73DMVCUj5RJnHzv_VS6gn0_uATxb32dr@mail.gmail.com>
	<4C61E5CA.5070604@sugarcrm.com>
	<AANLkTi=_hPcCJYoH1v-G1vdwY2PY1aLhfDJNKwDLsK9T@mail.gmail.com>
	<4C61F3EF.5030409@sugarcrm.com>
Date: Wed, 11 Aug 2010 06:03:45 +0200
Message-ID: <AANLkTiniS9zQMU6WubkqBOL40i3COnwpnMgTSWqXO2XJ@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Arvids Godjuks <arvids.godjuks@gmail.com>, Internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] Strict typing (was: Typehints)
From: phpwnd@gmail.com (Josh Davis)

On 11 August 2010 02:50, Stas Malyshev <smalyshev@sugarcrm.com> wrote:
> Hi!
>
>> First of all, I am talking about the typehinting syntax and mechanism
>> here. As Derick pointed out, current typehints are strict.
>
> Talking about "strict" vs. "non-strict" for class types is meaningless.

By "strict" typehints I meant that no typecasting occurs. Personally
I'm not fan of the "strict" vs "weak" denomination used here either.
I'd rather call them typechecking vs smartcasting.

> can consider them non-strict if you want - they convert if the conversion is
> available, just like the rest of PHP, with only note that conversion is
> *never* available.
> But it's just a semantic game because we are talking about different things
> here. Using the same syntax just confused you to think they are the same,
> but in PHP they are not. There are some languages where there's no primitive
> types or primitive types aren't different from classes - but PHP, for better
> or worse, as of now is not one of them.

I'm sorry but I have no idea what you're talking about there =\ PHP
has a bunch of different types, the current type hinting (typechecking
as per aforementionned denomination) ensures that the argument is the
right type and I hope that adding scalar type hints will not change
that.

> Again, it's just semantic games - you can call it "typehints" or not, your
> choice, but the fact is they did not fixate on the bitwise representation of
> the types - and we shouldn't start fixating on that now. They accept "1"
> when numeric value is needed, why can't you?

I very much can, it's just not my intention. I want to be able to use
type hinting/type checking as a sanity check. If I write a method
whose signature is foo(int $n) I signal my intention to only accept
integers. If a boolean somehow finds its way to that method, it means
that something wrong happened. If I wanted to accept any type of
variable then I wouldn't use a type hint and I would validate the
input with the filter extension. Or I would use type casting.

TL;DR version: "int $n" in the definition means I want an integer. If
I wanted any kind of variable but I wanted it to somehow represent a
number then I would look for a hint such as "number $n". I guess that
"(int) $n" is close enough, since that's what's being used everywhere
else.

> That's exactly what is wrong with it - developer should NOT expect "variable
> of certain type to be passed" (if we are talking about primitive types),
> because PHP is not a strictly typed language, it's a dynamic language.

If PHP was meant to prevent programmers from controlling the type of
their variables then I'm afraid there's been a misunderstanding and
I'd say that extending a feature called "type hinting" to cover all of
PHP's primitive types will only make it worse. I have always thought
that controlling the type of the variables used in userland was my
prerogative, and I suspect that quite a few users were led to believe
the same thing.

Derick's proposal allows for those users to control the type of their
variables and allows for those who care about the content of their
variables more than their type to do that as well.

> It does not change any behavior - right now there's two sets of objects in
> PHP - primitive types and classes. Values of primitive types can be
> converted into another type, implicitly or explicitly, objects of classes
> can not.

As a PHP user, I have no such notion I'm afraid. From my point of
view, there's not two sets of objects, there's about ~8 types, PHP's
core functions and operators do not care too much about those types
and convert them internally. That's all the users see.

I'm not sure what you meant by "objects of classes can not [be
converted into another type]". Arrays can be cast as booleans (false
is empty, true otherwise), objects can be cast as arrays (properties
become keys) and strings to objects (with a single property called
"scalar", leaving everybody wondering what's going on there.)

TL;DR: I always thought PHP would help me control the type of my
variables instead of forcing my userland code to mirror PHP's internal
functions.

PS: I think I've just figured out what you meant by "conversion". Were
you talking about the internal conversion rules used by PHP's internal
functions? Are those described somewhere in the manual?