Private, Protected, Public or Internal

[imir]

Ладно со старыми методами, там private по-умолчанию переехал из 12-й, это можно объяснить (не)злым умыслом. Но в новых модулях, кторые пишутся с нуля.. смотрим написанный недавно с нуля Asset leasing:

- все классы помечены internal final class AssetLease*
Все методы:
-все что можно private
- там где нельзя поставить private по смыслу - internal
- нельзя ни то, ни другое - [Hookable(false)]

ну т.е. не то что точки не заложены, а модуль целиком и полностью с особой паранойей закрыт изначально.

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

[Stitch_MS]

Цитата:

Сообщение от imir

Допускаю, что это задумано для того, чтобы репортили баги вместо заплаток

А ещё это освобождает вендора от неприятных раздумий типа «а не breaking ли change я сейчас пилю?»

[imir]

Цитата:

Сообщение от Stitch_MS

А ещё это освобождает вендора от неприятных раздумий типа «а не breaking ли change я сейчас пилю?»

Вот нашел специально, метод update() в таблице AssetLeaseIndexRateTable - [Hookable(false)]

Т.е. чтобы при апдейте записи по феншую через COC внутри транзакции что-то дописать, придется запрос делать в МС, тупо на табличный метод update? Либо МС избавился не только от неприятных раздумий, а в принципе.. либо одно из двух )

[Stitch_MS]

Цитата:

Сообщение от imir

Вот нашел специально, метод update() в таблице AssetLeaseIndexRateTable - [Hookable(false)]

Т.е. чтобы при апдейте записи по феншую через COC внутри транзакции что-то дописать, придется запрос делать в МС, тупо на табличный метод update? Либо МС избавился не только от неприятных раздумий, а в принципе.. либо одно из двух )

В этом случае достаточно к системному событию onUpdating или onUpdated обработчик написать? Но да, в целом выглядит так, будто крупные новые фичи закрываются намеренно.