Laravel 13, model yapılandırmasını PHP'nin newInstance() çağrılana dek hiç kontrol etmediği attribute'lara taşıyor

PHP 8.3'ü minimum sürüm olarak gerektiren Laravel 13, 17 Mart 2026'da yayınlandı ve framework yapılandırmasının büyük bir kısmını PHP attribute'larına taşıyor. Bu değişimin yanında, Gabriel Anhaia'nın dev.to'daki son bir yazısına göre geliştiricilerin yükseltme yapmadan önce anlaması gereken ince bir detay var: PHP, sınıflandırılmış sınıf derlendiğinde veya örneklendiğinde bir attribute'un sınıfını yüklemez veya doğrulamaz. #[Table] gibi bir model attribute'u bir isim ve argümanlar olarak saklanır ve referans verilen sınıf yalnızca biri reflection üzerinden üzerinde newInstance() çağırırsa çözümlenir.

Attribute'lara taşınanlar

Yazıya göre 13.x'in Eloquent dokümantasyonu artık model yapılandırmasını Illuminate\Database\Eloquent\Attributes namespace'indeki attribute'lar üzerinden sunuyor. #[Table], tablo adını key, keyType, incrementing, timestamps ve dateFormat dahil isimli argümanlarla birlikte kabul ediyor. #[Fillable], $fillable özelliğinin yerine geçebiliyor ve serileştirme dokümanları #[Hidden] ile #[Visible]ı $hidden ve $visible için alternatifler olarak konumlandırıyor. Sürüm notları deseni modellerin ötesine taşıyor: controller'larda #[Middleware] ve #[Authorize], job'larda #[Tries], #[Backoff] ve #[Timeout], ayrıca Eloquent, event'ler, bildirimler, validation, test ve resource serileştirmesine yayılan başka attribute'lar.

Model'i genişleten bir sınıfta bu mimari açıdan pek bir şey değiştirmiyor, çünkü kalıtım zaten sınıfı Eloquent'e bağlıyor ve PHP onu framework olmadan yükleyemiyor. Yazarın öne çıkardığı durum, framework üst sınıfı olmayan düz bir sınıfın yine de bu attribute'lardan birini taşıması.

PHP attribute'ları nasıl ele alıyor

PHP 8.0'da kabul edilen attribute RFC'si bilinçli bir ödünleşim yaptı. Derleme zamanında PHP, attribute'un adını dosyanın import'larına göre çözümler ve o adı argüman ifadeleriyle birlikte kaydeder; ama attribute sınıfını autoload etmez veya argümanların bir constructor ile eşleşip eşleşmediğini kontrol etmez. RFC'ye göre doğrulama yalnızca ReflectionAttribute::newInstance() çağrıldığında gerçekleşir; sınıfı declare etmek teknik olarak isteğe bağlıdır ve getAttributes() hiçbir zaman exception fırlatmayacak şekilde belirtilmiştir. Derleyici tarafından tanımlı attribute'lar istisnadır; kullanıcı tarafındaki attribute'lar derleme zamanında asla kontrol edilmez.

Import ifadesi de aynı ölçüde etkisizdir. PHP kılavuzu import etmeyi, autoloader devreye girmeden çözümlenen bir isim takma adı olarak derleme zamanı işlemi olarak tanımlıyor.

Fark edilmeden geçen senaryo

Yazı, kendi composer.json dosyasına sahip, gereksinimleri arasında Laravel bulunmayan ve framework yokken geçen testlere sahip bir domain paketi üzerinden ilerliyor. Bir pull request bir entity'nin üstüne #[Table('orders')] ve eşleşen use satırını ekliyor ve hiçbir şey bozulmuyor: sınıf derleniyor, örneklendirme çalışıyor, getAttributes() bir reflection nesnesi döndürüyor, getName() çözümlenmiş sınıf adını bildiriyor ve getArguments() saklanan argümanları döndürüyor. Yalnızca bir framework'ün yapacağı tek çağrı olan newInstance() bir Error fırlatıyor, çünkü hiçbir autoloader attribute sınıfını sunamıyor. Yazar, o tam betiği kendisinin çalıştırmadığı uyarısını ekliyor; bu nedenle anlatım, yakalanmış çıktıdan ziyade dokümante edilmiş davranışı yansıtıyor.

Sessiz bağımlılık neden yine de size mal oluyor

Kod çalışsa da import gerçektir ve domain namespace'i artık Illuminate\ içindeki bir sınıfı adlandırmaktadır. Yazı üç sonuç sıralıyor. Entity artık depolama detaylarını kodluyor, çünkü tablo adı tam da altıgen mimarinin bir adapter'a itmeye çalıştığı şeydir; üstelik tabloyu yeniden adlandıracak sonraki kişi bir domain sınıfını düzenler. Sorunu çalışma zamanında hiçbir şey ortaya çıkarmaz, çünkü domain testleri attribute'lar üzerinden asla reflection yapmaz ve Laravel bir model olmayan sınıftaki attribute'u hiç okumaz; sadece her attribute üzerinden reflection yapan bir şey (genel bir mapper, bir serializer veya sınıfı modele dönüştüren sonraki bir refactor) bu hatayla karşılaşır. Ve desen kolayca yayılır, çünkü attribute'lar kompakt ve zararsız görünür; az önce bunları kullanan birkaç modeli okumuş bir yapay zeka kodlama ajanı, yazdığı bir sonraki sınıfta aynı desene başvuracaktır.

Statik analizle koruma

PHP bu davranışı doğru kabul ettiği için yazı, attribute adının açıkça göründüğü AST'yi okuyan araçlarla yakalamayı öneriyor. Deptrac'ın use analizörü import ifadelerini inceler; tek bir use satırı bağımlılığı kaydetmesi için yeterlidir; framework'ü kendi katmanına yerleştirmek ve domain katmanına hiçbir bağımlılığa izin vermemek bunu engeller. Deptrac ayrıca ters kontrol için yararlı bir attribute toplayıcısıyla gelir; örneğin kalıcılık attribute'u taşıyan sınıfları gruplamak gibi. Tam olarak sorun yaratan satırı adlandıran bir hata mesajı için yazı, özel bir PHPStan kuralı öneriyor.

Neden önemli

Attribute tabanlı yapılandırma framework kodunu daha kısa hale getiriyor; ama kazara coupling'i hem çalışma zamanı hem de sıradan testler için görünmez kılıyor. Framework'ten bağımsız bir paket, hiçbir testin çalıştırmadığı ve hiçbir constructor'ın gerektirmediği bir satır aracılığıyla Laravel'e bağımlı hale kayabilir. Laravel 13'e yükselen veya yapay zeka ajanlarının ona karşı kod yazmasına izin veren ekipler, mimari sınırlar için uygulama noktası olarak statik analizi görmelidir, çünkü PHP'nin kendisi asla alarmı çalmayacaktır.