Scalar Type Intentions

Hi, Adam

I just get the feeling that this is exactly what we're currently discovered
in some other threads in this mailing-list.
We're now getting more and more closer to what we really want and a good
way to write it the PHP-way.

Please try to get a rough overview over the last messages we wrote on the
following threads:

• [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
• RE: [PHP-DEV] Scalar type hinting

The second one is quite big ;) and sometimes the messages contain only
religious stuff like "This will never be, go away" - but that's just
because we're in discussion. Like the wind blows. But I think we'll get to
list of rock-solid possible solutions here.

I think we'll soon create a RFC for that and discuss it after we have it
"on one paper".
I would kind-of like the idea to add the *scalar *type in addition just to
avoid objects or arrays in there, but let's look how the discussion goes.

Bye
Simon

2012/3/1 Adam Jon Richardson adamjonr@gmail.com

First, phpunit is a fantastic tool! I'm thankful for your contributions to
all of the PHP community (especially with the code coverage capabilities.)

I speak to your 2 points inline below:

On Wed, Feb 29, 2012 at 9:36 PM, Sebastian Bergmann <sebastian@php.net

wrote:

However, the aliases would allow developers to better communicate
intentions AND provide more information for IDE's and static analyses
tools.

1. You are trying to solve a social problem through technology. That
   usually does not work.

I believe technology can provide effective tools for social problems,
although I won't go so far as to say that it usually does work. More
importantly, I believe programming is riddled with social problems:

"Let us change our traditional attitude to the construction of programs.
Instead of imagining that our main task is to instruct a computer what to
do, let us concentrate rather on explaining to human beings what we want a
computer to do."

D. Knuth

2. What you want to achieve is already possible through docblocks.

The greater part of the proposal rests on the general scalar hint. That
said, I still believe the aliases for the scalars hold value. Sure, the
communicative aspect of the aliases can be achieved through use of
docblocks. However, in cognitive psychology and human factors research,
proximity of relevant information plays a role in perception and
processing, and I would posit that code with the type intentions displayed
closer to the actual body of the function would hold benefits (this would
be very testable, though, and research could prove me wrong.) When
available, the scalar aliases could then be used to help auto-generate the
docblocks.

I would appreciate the scalar hinting, along with the aliases I outlined
very much in my code. I believe that this form of hinting stays true to the
PHP principles outlined in Richard's PHP Philosophy thread (a great read),
and I believe it helps developers who want to better enforce (scalar
hinting) and communicate (scalar aliases) the intentions of their code.

Thank you for the feedback,

Adam

However, following your logic, class type hinting was a mistake?

The Type Hinting we currently have for arrays, callables, classes, and
interfaces is not a mistake. Why? Because the types in question are not
affected by the "type juggling".

--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/

Pierre Joye wrote:

usually does not work.

2. What you want to achieve is already possible through docblocks.
   I am not saying that I like the idea of scalar type arguments, but you
   keep saying that docblocks solve such issue. They are totally
   unrelated to what is discussed here, they are documentations. They
   have nothing to do with runtime information (The same concept applied
   to the annotations, if you remember it).

But one of the reasons given for wanting this is as simple documentation?

Does providing more checks at runtime actually add anything when in many cases
we already need to check for valid input anyway. I can't help thinking that in
many cases people proposing this are working on a basis that the variables they
are passing are fully nailed down as to what is in them? When in practice we are
not passing well typed variables around - until they have been checked.

It would be interesting to establish just how many developers already use IDE's
which provide all of this hinting and more important detailed error checking
which does not rely on adding anything more to the runtime engine. I kill most
of these problems before the scripts ever get run anyway ...

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

Yes, I agree, the casting (or the failing to cast) has to happen on entry,
for the reasons that you have very well explained.

However, I cannot understand what it means to cast an object to a scalar.
Does it always mean casting to string? Wouldn't that be slow in many cases?
Simple example:

class A {
public $value = 1234;
public function __toString(){ return (string)$this->value; }
}

function foo( int $x ) { // here "int" is used as an alias to "scalar" as
you suggest
return $x + 1;
}

$a = new A;
foo( $a ); // casting $a to scalar upon calling, as it is possible after
all

In this example, the integer value will have to be cast to a string only to
be cast back to integer (unless something else happens under the hoods that
I am not aware).

Lazare INEPOLOGLOU
Ingénieur Logiciel

2012/3/1 Adam Jon Richardson adamjonr@gmail.com

On Thu, Mar 1, 2012 at 4:36 AM, Lazare Inepologlou linepogl@gmail.comwrote:

And, what if PHP added the following aliases for the hint scalar:

• bool

• int

• float

• string

If an object has a __toString method, does it qualify as a valid value to
be passed to a scalar argument? In my opinion, it should.

Your suggestion has a future compatibility problem. The introduction of
new type casting methods (like __toInt or like __castTo) is an open
possibility. In such a case, if those keywords are nothing but aliases for
"scalar", then there will be no way to choose which type casting method
should be chosen.

Lazare INEPOLOGLOU
Ingénieur Logiciel

You raise interesting points, Lazare, but I don't believe the
compatibility issues you're concerned about are valid.

Failing fast, similar to the Poka-Yoke principal in manufacturing,
suggests that system failure should occur as soon as possible to reduce
software bugs:
http://www.martinfowler.com/ieeeSoftware/failFast.pdf

Consider the following example:

// example class that does not implement __toString()
class test{
}

function foo($arg1, $arg2, $arg3){
if ($arg1) {
return "The answer is: " . $arg1;
}

if ($arg2) {
return "The answer is: " . $arg2;
}

if ($arg3) {
return "The answer is: " . $arg3;
}
}

$test = new test();

echo foo($arg1 = "string", $arg2 = 100, $arg3 = $test); // echos The
answer is: string
echo foo($arg1 = false, $arg2 = 100, $arg3 = $test); // echos The answer
is: 100
echo foo($arg1 = false, $arg2 = false, $arg3 = $test); // catchable fatal
error

A developer using this function would only see this issue some of the
time, as this code fails late WITHIN some branches of the function, and the
bug is harder to identify.

We can do better, though. If the scalar type hint were applied, users
would merely have to cast the object to a string ON ENTRY to the function
(and, of note, this would work for your __toInt and __castTo concerns):

echo foo($arg1 = "string", $arg2 = 100, $arg3 = (string)$test);
// catchable fatal error

Because the cast is performed on entry to the call, the bug shows up
immediately. I would argue that this code is clean (the cast to string in
the foo() call is a small amount of noise/keystrokes), visibly conformant
to the intentions of the foo() function, and more likely to catch bugs
early on in the process.

Adam