Здравствуйте, Евгений Музыченко, Вы писали:

A>>Так там ЕСТЬ тип/класс. Просто он имплиситный.
ЕМ>"Имплиситных" синглтонов не бывает. Если у Вас есть один апельсин — какие могут быть основания называть "синглтоном" хоть непосредственно его, хоть тип/класс фрукта?

Хорошо, начнём от истоков.

Синглтон это паттерн проектирования. С этим, надеюсь, ты спорить не будешь?

Далее. Паттерн проектирования отражает некое представление о правильном устройстве чего-нибудь. Синглтон отражает следующее: "Экземпляр [чего-нибудь] может быть только один". Теперь смотрим, что ты написал:

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

Если ты считаешь, что элемент типа "подвал" может быть только один, и копировать его бессмысленно, это буквально и есть синглтон. Синглтоннее не бывает.

Паттерн этот является ошибкой проектирования (быдло называет их "антипаттерны", но такой подход неявно приписывает обычным паттернам качество "хороший", "безошибочный", поэтому я этим словом не пользуюсь). Ошибка тут в том, что в природе даже конь с двумя... подвалами нет-нет, да уродится. Вопрос времени, когда это противоречие всплывёт в коде. А если часто и много решать задачи заданной предметной области, это время существенно сокращается. Поэтому пара-тройка лет плотной работы с разметкой отучает пользоваться id в тех местах, где он не требуется стандартом, а в тех, где требуется — думать о замене.

A>>Встроить шаблонизатор в стандарт.

ЕМ>А точно надо? Какой процент задач в HTML/CSS он мог бы решить без привлечения JS?

Я не говорил, что надо. Это вырвано из контекста. Я сказал, что если это сделать де-юре (де-факто все и так пишут одно и то же со времён Мусташа, включая синтаксис фигурных скобок и использование data-атрибутов), то неявно инстанцирование станет явным. Это чисто мысленное упражнение, если кому-то без инстанцирования трудно понять, где тут типы, а где экземпляры.

Кроме того, сейчас шаблоны и де-юре наполовину стандартизированы, со стороны разметки. Если помнишь, раньше для них все юзали <script>, а сейчас <template>.

A>>Ладно, я понял твою позицию: проблемы нет, оставить всё как есть.

ЕМ>Проблемы как раз есть, но вряд ли стоит начинать их решение именно с обсуждаемой. Это ж даже не проблема — так, мелкое неудобство.

Мой список претензий к HTML/JS/CSS длиной до Луны, периодически я что-то из него озвучиваю.

В данном же случае, прежде, чем критиковать, надо понять, как нужно было сделать правильно и можно ли вообще что-то улучшить.

Здравствуйте, Евгений Музыченко, Вы писали:

A>>Так там ЕСТЬ тип/класс. Просто он имплиситный.
ЕМ>"Имплиситных" синглтонов не бывает. Если у Вас есть один апельсин — какие могут быть основания называть "синглтоном" хоть непосредственно его, хоть тип/класс фрукта?

Хорошо, начнём от истоков.

Синглтон это паттерн проектирования. С этим, надеюсь, ты спорить не будешь?

Далее. Паттерн проектирования отражает некое представление о правильном устройстве чего-нибудь. Синглтон отражает следующее: "Экземпляр [чего-нибудь] может быть только один". Теперь смотрим, что ты написал:

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

Если ты считаешь, что элемент типа "подвал" может быть только один, и копировать его бессмысленно, это буквально и есть синглтон. Синглтоннее не бывает.

Паттерн этот является ошибкой проектирования (быдло называет их "антипаттерны", но такой подход неявно приписывает обычным паттернам качество "хороший", "безошибочный", поэтому я этим словом не пользуюсь). Ошибка тут в том, что в природе даже конь с двумя... подвалами нет-нет, да уродится. Вопрос времени, когда это противоречие всплывёт в коде. А если часто и много решать задачи заданной предметной области, это время существенно сокращается. Поэтому пара-тройка лет плотной работы с разметкой отучает пользоваться id в тех местах, где он не требуется стандартом, а в тех, где требуется — думать о замене.

A>>Встроить шаблонизатор в стандарт.

ЕМ>А точно надо? Какой процент задач в HTML/CSS он мог бы решить без привлечения JS?

Я не говорил, что надо. Это вырвано из контекста. Я сказал, что если это сделать де-юре (де-факто все и так пишут одно и то же со времён Мусташа, включая синтаксис фигурных скобок и использование data-атрибутов), то неявное инстанцирование станет явным. Это чисто мысленное упражнение, если кому-то без инстанцирования трудно понять, где тут типы, а где экземпляры.

Кроме того, сейчас шаблоны и де-юре наполовину стандартизированы, со стороны разметки. Если помнишь, раньше для них все юзали <script>, а потом появился специальный <template>.

A>>Ладно, я понял твою позицию: проблемы нет, оставить всё как есть.

ЕМ>Проблемы как раз есть, но вряд ли стоит начинать их решение именно с обсуждаемой. Это ж даже не проблема — так, мелкое неудобство.

Мой список претензий к HTML/JS/CSS длиной до Луны, периодически я что-то из него озвучиваю.

В данном же случае, прежде, чем критиковать, надо понять, как нужно было сделать правильно и можно ли вообще что-то улучшить.