ну значит я прав, получается, и вы два давна

ну вот)) два давна и два говна. эквивалент

а аргументов так и нет

слабые

Можешь тешить себя этой мыслью :)

я просто в восторге, что два давна потерялись

от простого вопроса

1. Типизация. Если кто-то зависит от типизированного айдишника клиента, ты никак не можешь случайно скормить ему айдишник заказа. Если ид - просто int, этого не добиться
2. Если есть типизация - ты всегда можешь найти того, кто от этого айди зависит. Если ид - простой int, тебе для трекинга зависимостей тебе нужно наворачивать какие-то ебанутые конвеншены по именованию переменных или методов и эта шляпа вообще не работает.
3. Если за одну таблицу у тебя отвечает две и более сущностей - имея общий тип UserId ты всегда можешь понять, что речь об одном и том же объекте, но из разных контекстов. Если ид - простой int, то удачи тебе в реализации такого сравнения.

Есть что-то ещё, но сходу вспомнилось это.

Теперь твои аргументы в пользу того, что id - не объект

3. Если за одну таблицу у тебя отвечает две и более сущностей - имея общий тип UserId ты всегда можешь понять, что речь об одном и том же объекте, но из разных контекстов.
т.е. в контексте субд у тебя "id = объект" - это одна сущность?

Причём тут контекст бд? Изначально речь шла о маппинге доктрины и было сказано, что ид - объект, что вызвало у тебя полыхание. Давай в контексте кода и останемся. Как оно в базе - вопрос второй

без практического примера я хер что пойму. поэтому или объясни внятно, или я подожду того, кто сможет объяснить

ну так ты же начал заливать про сущности и таблицы

у меня id  = объект только в случаях связанностей, т.е. <relation>_id = объект,
но никак не id = объект.  ибо id - это всегда скаляр

В одной таблице "живут две сущности".
Отличаются неким признаком друг от друга

То есть ты где-то случайно можешь вместо id клиента передать id заказа и никак не выяснишь этого?

та хоть вся таблица состоит из сущностей, id всегда скаляр

Какие в этом профиты?

я хз о чём вы

практический пример дайте

чтобы понять