常連

### 質問の経緯
PHP の empty() でわけのわからない仕様を見つけました。
下記を実行してみてください。

実行：https://3v4l.org/ZeZFk
```PHP
<?php
class Car
{
    protected array $tags;

    public function __get(string $prop): mixed
    {
        if (property_exists($this, $prop)) {
            return $this->{$prop};
        }
    }

    public function __set(string $prop, mixed $val): void
    {
        if (property_exists($this, $prop)) {
            $this->$prop = $val;
        }
    }
}

class CarMapper
{
    public function test(Car $car): void
    {
        echo 'そのままだとtrueになる'.PHP_EOL;
        var_dump(empty($car->tags)); // bool(true)

        echo '代入するとfalseになる'.PHP_EOL;
        $tags = $car->tags;
        var_dump(empty($tags)); // bool(false)
    }
}

$car = new Car();
$car->tags = ['tag1'];
$carMapper = new CarMapper();
$carMapper->test($car);
```

なんと、「そのままだとtrueになる」のに、「代入するとfalseになる」のです。わけがわかりません…。

### 調べたこと
一応マニュアルにはこのような記載がございましたが、別に __isset() なんて宣言していませんのでこの記載は関係ないと思いますし。（つまり __isset() が宣言されていなければ empty() は平常運転するだろうと解釈できますし。）

> オブジェクトのアクセス不能なプロパティに対して empty() を使用した場合は、もしオーバーロードメソッド __isset() が宣言されていればそれをコールします。
> https://www.php.net/manual/ja/function.empty.php


それにもし「> アクセス不能なプロパティに対して empty() を使用」していることが何か関係しているとしても、そもそも最初の var_dump() は「アクセス不能なプロパティを __get() で取得した結果に empty() を使用」していると捉えるべきだと思うのです。

つまりこうではなくて、
```PHP
empty(アクセス不能なプロパティ)
```

こう捉えるべきだと思うのです。
```PHP
empty(アクセス不能なプロパティを __get() で取得した結果)
```

なぜならこの outer() は、inner() の結果を利用しているためです。empty() だって中の結果を利用してよ！と思います。なんで中の結果を作る前にアクセスの不能性を判定するのでしょうか。わけがわかりません…。
```PHP
echo outer(inner());
function inner(){return 'inner';}
function outer($str){return 'outer'.$str;}
```

### 質問事項
改めまして質問は２つです。

➀いったいどういうロジックで「そのままだとtrueになる」のに、「代入するとfalseになる」という事象になるのでしょうか？
➁そしてどのようにして「$car->tags のような値（配列のプロパティ）が空配列であること」を確認すべきなのでしょうか？

お詳しい方、よろしくお願い致します。

※尚、empty() だけでなく isset() も同様の事象でした。

### 補足
質問の➁について、ひとまず Car に以下のような __isset() を置いて解決できました。
```PHP
    public function __isset(string $prop): bool
    {
        return property_exists($this, $prop);
    }
```

ならば改めて質問になりますが

➂この __isset() はすべてのクラスで絶対に置いておくべきだと思ったのですが、あって困ることはございますか？

もし「オレは empty() や isset() は絶対に通さないのだ！」というなら不要でしょうけれど、あって困ることがなければ備えて置いておくべきだと思いました。（もちろんこれを置かず、➁への回答としてより良いものあれば引き続き➁も募集したいです。）

PHPで代入すると結果がかわる事象について

### 発生している問題

Visual Studio Codeのファイル間検索(Ctrl + Shift + f)にて、ワークスペース内のあるファイルに検索文字列が含まれている場合、そのファイルがVSCodeエディタで開かれている場合はヒットするのに、ファイルを閉じる(ワークスペース上にはある)となぜかヒットしなくなる。

なお、同じワークスペースにあるファイルでも症状が再現するファイルとしないファイルがあり、
再現するファイルは*.tsファイル(UTF8)、一方再現しないファイルは*cppファイル(EUC-JP)です。
文字コードが問題のような気はしましたが、同じ.tsファイルで症状の出る/出ないがエディタで開いているかどうかで決まるのでまた別問題に思えます。

### 補足情報（FW/ツールのバージョンなど）

Visual Studio Codeはポータブル版の1.74.2



Visual Studio Code(VSCode)のファイル間検索にて、あるファイルに検索文字列が含まれているのに、エディタで開かれている時しかヒットしない

Djangoでログイン認証画面を作成しています。
そこでふと、疑問に思ったので、質問させてください。

ECサイトなどのショッピングサイトで、ログイン者の情報などをセッションとクッキーを使って管理していると思います。

例えば下記のような形式でセッションIDがクッキーに保存されているとき

```
(key)        (value)
SESSION_KEY: asioudasfdawefas
```

ChromeプラグインのEditThisCookieなどのツールを用いて、ブルートフォース攻撃でvalueを改変・編集をした場合に容易に第三者になりますしてログインされてしまうんじゃないかと思ってしまいました。

ログイン画面のときのブルートフォース攻撃は、認証に3回失敗したら、しばらく無効になるとか対策をよく見ますが、クッキー改変による不正ログインに対しては、対策があるとはまったく聞きませんし、見たこともありません。

もし、そのような対策がしかれているのであれば、ご教示いただけませんでしょうか？

逆に、対策がされていないとなると、世の中のログインサイトは自分が思っている以上に相当危険な場所なのでしょうか？