PHPでの変数の型キャスト、これを行う実際的な理由は何ですか？

私たちのほとんどが知っているように、PHPには弱い型付けがあります。そうでない人のために、PHP.netは次のように述べています。

PHPは、変数宣言で明示的な型定義を必要としません（またはサポートしません）。変数のタイプは、変数が使用されるコンテキストによって決まります。

好きでも嫌いでも、PHPはその場で変数を再キャストします。したがって、次のコードは有効です。

$var = "10";
$value = 10 + $var;
var_dump($value); // int(20)

PHPでは、次のように変数を明示的にキャストすることもできます。

$var = "10";
$value = 10 + $var;
$value = (string)$value;
var_dump($value); // string(2) "20"

それはすべてクールです...しかし、私の人生にとって、これを行うための実用的な理由を考えることはできません。

Javaのような、それをサポートする言語での強い型付けの問題はありません。それは大丈夫で、私はそれを完全に理解しています。また、関数パラメーターの型ヒントを認識し、その有用性を完全に理解しています。

型キャストに関する問題は、上記の引用文で説明されています。PHPで型を自由に交換できる場合は、型を強制的にキャストした後でも可能です。また、操作で特定のタイプが必要な場合にオンザフライで実行できます。これにより、次のことが有効になります。

$var = "10";
$value = (int)$var;
$value = $value . ' TaDa!';
var_dump($value); // string(8) "10 TaDa!"

だからポイントは何ですか？

PHPでユーザー定義型キャストが理にかなっているこの理論的な例を見てみましょう。

1. キャスト変数$fooをint→ として強制します(int)$foo。
2. 変数に文字列値を保存しようとしました$foo。
3. PHPは例外をスローします!! ←それは理にかなっています。突然、ユーザー定義型キャストの理由が存在します！

PHPが必要に応じて切り替えを行うという事実により、ユーザー定義型キャストのポイントが曖昧になります。たとえば、次の2つのコードサンプルは同等です。

// example 1
$foo = 0;
$foo = (string)$foo;
$foo = '# of Reasons for the programmer to type cast $foo as a string: ' . $foo;

// example 2
$foo = 0;
$foo = (int)$foo;
$foo = '# of Reasons for the programmer to type cast $foo as a string: ' . $foo;

もともとこの質問をしてから1年後、誰が実際の環境でタイプキャストを使用していると思いましたか？敬具。

要件は、レストランメニューのウェブサイトに金額を表示することでした。サイトの設計では、表示が次のようになるように、末尾のゼロを削除する必要がありました。

Menu Item 1 .............. $ 4
Menu Item 2 .............. $ 7.5
Menu Item 3 .............. $ 3

私が見つけた最良の方法は、変数をフロートとしてキャストすることでした。

$price = '7.50'; // a string from the database layer.
echo 'Menu Item 2 .............. $ ' . (float)$price;

PHPは、フロートの末尾のゼロを削除し、フロートを連結用の文字列として再キャストします。

弱く型付けされた言語では、型キャストは型付き操作のあいまいさを排除するために存在します。そうでない場合、コンパイラー/インタープリターは順序または他の規則を使用して、どの操作を使用するかの仮定を行います。

通常、PHPはこのパターンに従うと思いますが、私がチェックしたケースでは、PHPはそれぞれで直感に反して動作しました。

JavaScriptを比較言語として使用している場合を次に示します。

文字列の連結

別のがあるので、明らかにこれはPHPでの問題ではありません文字列連結（.）と追加（+）演算子は。

var a = 5;
var b = "10"
var incorrect = a + b; // "510"
var correct = a + Number(b); // 15

文字列の比較

多くの場合、コンピューターシステムでは「5」は「10」よりも大きいため、数値として解釈されません。PHPではそうではありません。PHPは、両方が文字列であっても、数字であることを認識し、キャストの必要性を取り除きます）：

console.log("5" > "10" ? "true" : "false"); // true

echo "5" > "10" ? "true" : "false";  // false!

関数シグネチャの型付け

PHPは、関数のシグネチャに対して最低限の型チェックを実装していますが、残念ながら、非常に欠陥があるため、ほとんど使用できません。

私は何か間違っているかもしれないと思っていましたが、ドキュメントへのコメントは、配列以外の組み込み型はPHP関数シグネチャで使用できないことを確認しています-エラーメッセージは誤解を招くものです。

function testprint(string $a) {
    echo $a;
}

$test = 5;
testprint((string)5); // "Catchable fatal error: Argument 1 passed to testprint()
                      //  must be an instance of string, string given" WTF?

そして、私が知っている他の言語とは異なり、理解できる型を使用しても、その引数（must be an instance of array, null given）にnullを渡すことはできません。なんてばかな。

ブール解釈

[ 編集 ]：これは新しいものです。私は別のケースを考えましたが、やはりロジックはJavaScriptと逆になっています。

console.log("0" ? "true" : "false"); // True, as expected. Non-empty string.

echo "0" ? "true" : "false"; // False! This one probably causes a lot of bugs.

結論として、私が考えることができる唯一の有用なケースは...（ドラムロール）

型の切り捨て

つまり、あるタイプの値（たとえば文字列）があり、それを別のタイプ（int）として解釈し、そのタイプの値の有効なセットの1つに強制する場合：

$val = "test";
$val2 = "10";
$intval = (int)$val; // 0
$intval2 = (int)$val2; // 10
$boolval = (bool)$intval // false
$boolval2 = (bool)$intval2 // true
$props = (array)$myobject // associative array of $myobject's properties

（より多くの値を含むタイプへの）アップキャストが実際にあなたにどんな利益をもたらすかはわかりません。

したがって、私はあなたの提案されたタイピングの使用に同意しませんが（本質的に静的タイピングを提案していますが、型に強制キャストされた場合にのみエラーをスローするという曖昧さにより混乱を引き起こします）、それは良いと思います質問は、明らかにキャストするためには、持っている非常に PHPで少し目的を。

あなたは弱い/強いタイプと動的/静的なタイプの概念を混ぜています。

PHPは脆弱で動的ですが、問題は動的型の概念にあります。つまり、変数には型がなく、値にはあります。

「型キャスト」とは、元の型とは異なる型の新しい値を生成する式です。変数に何もしません（関係する場合）。

キャスト値を定期的に入力する1つの状況は、数値SQLパラメーターです。SQLステートメントに挿入する入力値をサニタイズ/エスケープするか、（はるかに優れた）パラメーター化されたクエリを使用する必要があります。ただし、整数でなければならない値が必要な場合は、キャストする方がはるかに簡単です。

考慮してください：

function get_by_id ($id) {
   $id = (int)$id;
   $q = "SELECT * FROM table WHERE id=$id LIMIT 1";
   ........
}

最初の行を$id省略した場合、SQLインジェクションの簡単なベクトルになります。キャストは、それが無害な整数であることを確認します。何らかのSQLを挿入しようとすると、単にクエリが実行されます。id=0

私が見つけたPHPでの型キャストの1つの使用法：

私は、データベースからデータを取得するためにサーバー上のPHPスクリプトにhttpリクエストを行うAndroidアプリを開発しています。スクリプトは、データをPHPオブジェクト（または連想配列）の形式で保存し、JSONオブジェクトとしてアプリに返します。型キャストがなければ、次のようなものを受け取ります。

{ "user" : { "id" : "1", "name" : "Bob" } }

しかし、(int)ユーザーのIDにPHPオブジェクトを格納するときに、PHPの型キャストを使用すると、代わりにアプリに返されます：

{ "user" : { "id" : 1, "name" : "Bob" } }

JSONオブジェクトがアプリで解析されると、IDを整数に解析する必要がなくなります。

参照してください、非常に便利です。

1つの例は__toStringメソッドを持つオブジェクトです： $str = $obj->__toString();vs $str = (string) $obj;。2番目の入力ははるかに少なく、余分なものは句読点であり、入力に時間がかかります。他の人も同意しないかもしれませんが、私はそれがより読みやすいと思います。

別の方法は、単一要素の配列を作成することです： array($item);vs (array) $item;。これにより、配列内にスカラー型（整数、リソースなど）が配置されます。
または、$itemオブジェクトの場合、そのプロパティは値のキーになります。ただし、object-> array変換は少し奇妙だと思います：privateおよびprotectedプロパティは配列の一部であり、名前が変更されています。PHPのドキュメントを引用するには、プライベート変数には変数名の前にクラス名が付いています。保護された変数には、変数名の前に「*」が付加されます。

別の用途は、GET / POSTデータをデータベースに適したタイプに変換することです。MySQLはこれ自体を処理できますが、より多くのANSI準拠サーバーがデータを拒否する可能性があると思います。データベースについてのみ言及する理由は、他のほとんどの場合、データはある時点でそのタイプに応じて実行されるためです（つまり、int / floatでは通常、計算が実行されるなど）。

このスクリプト：

$tags = _GET['tags'];
foreach ($tags as $tag) {
    echo 'tag: ', $tag;
}

は最初のケースでは配列を返しますが、2番目のケースでは配列を返さscript.php?tags[]=oneないためscript.php?tags=one、で正常に実行されますが、で失敗し_GET['tags']ます。スクリプトは配列を予期するように記述されているため（そして、スクリプトに送信されるクエリ文字列を制御することはできません）、次の結果を適切にキャストすることで問題を解決できます_GET。

$tags = (array) _GET['tags'];
foreach ($tags as $tag) {
    echo 'tag: ', $tag;
}

また、迅速でダーティな方法として使用して、信頼できないデータが何かを壊さないようにすることもできます。

$amount = (float) $_POST['amount'];

if( $amount > 0 ){
    $remoteService->doacalculationwithanumber( $amount );    
}

明らかにこれには欠陥があり、ifステートメントの比較演算子によって暗黙的に処理されますが、コードの実行内容を正確に把握するのに役立ちます。

私が頻繁に使用するPHP再キャスト変数の「使用」は、外部ソース（ユーザー入力またはデータベース）からデータを取得する場合です。コーダー（開発者とは言わなかったことに注意してください）が、さまざまなソースから利用可能なさまざまなデータ型を無視する（学習しない）ことができます。

私が継承し、まだ維持しているコードを持つ1人のコーダー（私は開発者とは言わなかったことに注意してください）は、スーパー変数に返される文字列"20"と$_GET20 + 20彼女がそれを追加するときの整数演算の間に違いがあることを知らないデータベース内の値。彼女はコードが2つの文字列（MySQLからの値とからの値）を「追加」してintを取得したので、PHPが.文字列の連結に使用し+、他の言語とは異なります。varcahr$_GET

これは実用的な例ですか？コーダーがどのデータ型を使用しているかを知らなくても済むようにするという意味でのみです。個人的には嫌いです。