Я правильно понимаю, что при любом изменении состояния, оно каждый раз полностью перестраивается?
И еще я вижу это рекомендуемая практика хранить в состоянии коллекции данных. Это нормально смотрится для сингл пэйдж приложения. Но если у меня много экранов, получается состояние хранит наборы неиспользуемых данных. Или они как-то подчищаются?
abstract class singleton {
public static function getInstance() {
static $instance = null;
if(is_null($instance)) {
$instance = new static();
}
return $instance;
}
protected final function __construct() {}
protected final function __clone() {}
protected final function __wakeup() {}
}
Кстати, на мой взгляд, ставить лабел под инпут, а не поверх него, более лучшее решение. Это позволит прятать лабел не при фокусе, а только когда в инпут был вставлен текст, именно так, как ведет себя дефолтный placeholder в последних версиях хрома. В свое время накатал плагин с таким подходом github.com/claustrofob/Default-Text.
А вообще, мы можем взять любой хэш из таблицы, и брутфорсить его по старой схеме. Теоретически, если мы увели таблицу юзеров с солью, то достаточно знать хотя бы один хэш из таблицы хэшей, чтобы взломать все пароли.
По-моему, вы неправильно считаете.
При обычной системе нам придётся генерировать все хэши самостоятельно и сравнивать его с тем едиственным, который привязан к юзеру. С новой системой у нас намного выше вероятность угадать пароль для каждого сгененированного нами хэша. Скорость поиска хэша в таблице с индексами будет относительно стабильной с ростом базы, а скорость генерации хэшей будет пропорционально расти.
А в сочетании с медленным хэшем, новый способ очень ускорит подбор.
Все равно не понимаю, чем сложнее подобрать пароль к любому из миллиарда хэшей, чем к одному? Получается, растёт размер базы и уязвимость. То, что такую базу на флэшке не унести, сомнительное преимущество.
Для reference типов особо смысла нет, а для value типов есть.
https://docs.swift.org/swift-book/ReferenceManual/Expressions.html#ID544
И еще я вижу это рекомендуемая практика хранить в состоянии коллекции данных. Это нормально смотрится для сингл пэйдж приложения. Но если у меня много экранов, получается состояние хранит наборы неиспользуемых данных. Или они как-то подчищаются?
Вообще-то есть. CSS свойство will-change позволяет сообщить браузеру об изменениях, которые будут применены к элементу.
неплохо было бы сократить, используя позднее статическое связывание
При обычной системе нам придётся генерировать все хэши самостоятельно и сравнивать его с тем едиственным, который привязан к юзеру. С новой системой у нас намного выше вероятность угадать пароль для каждого сгененированного нами хэша. Скорость поиска хэша в таблице с индексами будет относительно стабильной с ростом базы, а скорость генерации хэшей будет пропорционально расти.
А в сочетании с медленным хэшем, новый способ очень ускорит подбор.