Кому как удобно. Если есть вероятность правки данных пользователем (и эта правка критична, т.к. например в тех же героях 3/HOTa сохранёнки никак не защищены от подобного) - можно использовать без этой фичи, в методе распаковки можно выбрать вариант пересоздания объектов. Тогда также будет сохранена возможность сохранения ссылок и цепочки прототипов.
Ну а вообще Вы правы. Я когда писал предыдущий комментарий понял, что особой необходимости держать там eval нет, можно его опционально включать, а по умолчанию выключить.
Естественно нет. Я по этому и написал выше, что "такие переменные на самом деле трудно восстановить, потому что они могут меняться по ходу работы объекта, а доступа из вне к ним нет" и что практического применения втыкания переменных в конструктор может и не быть.
Можно в принципе без eval обойтись, если для пересоздания объекта не критично, чтобы аргументы конструктора отсутствовали (т.к. всё равно после пересоздания произойдёт merge с сериализацией).
Это нужно только для тех случаев, в которых аргумент в конструкторе критичен. Например, когда сам конструктор устанавливает свои внутренние переменные (которые не содержатся в объекте) на основе переданных данных. Но такие переменные на самом деле трудно восстановить, потому что они могут меняться по ходу работы объекта, а доступа из вне к ним нет. Т.е. по сути, случаи, в которых нужно делать eval для сборки аргументов конструктора, высосаны из пальца.
Вот небольшой пример:
function town(country){
var isCapitol=0;
if(country=='russia') isCapitol=1;
this.country=country;
this.getCapitol=()=>isCapitol;
}
let msk=new town('russia');
console.log(msk.getCapitol());
В этом случае, после сериализации/десериализации объекта, метод getCapitol будет работать неправильно, т.к. связанная с ним переменная isCapitol обнулится. Но если использовать текущий метод десериализации, то она сохранится.
Может и можно. Сейчас посмотрел - конструктор объекта отдаёт [[scopes]]
Кому как удобно. Если есть вероятность правки данных пользователем (и эта правка критична, т.к. например в тех же героях 3/HOTa сохранёнки никак не защищены от подобного) - можно использовать без этой фичи, в методе распаковки можно выбрать вариант пересоздания объектов. Тогда также будет сохранена возможность сохранения ссылок и цепочки прототипов.
Ну а вообще Вы правы. Я когда писал предыдущий комментарий понял, что особой необходимости держать там eval нет, можно его опционально включать, а по умолчанию выключить.
Естественно нет. Я по этому и написал выше, что "такие переменные на самом деле трудно восстановить, потому что они могут меняться по ходу работы объекта, а доступа из вне к ним нет" и что практического применения втыкания переменных в конструктор может и не быть.
Можно в принципе без eval обойтись, если для пересоздания объекта не критично, чтобы аргументы конструктора отсутствовали (т.к. всё равно после пересоздания произойдёт merge с сериализацией).
Это нужно только для тех случаев, в которых аргумент в конструкторе критичен. Например, когда сам конструктор устанавливает свои внутренние переменные (которые не содержатся в объекте) на основе переданных данных. Но такие переменные на самом деле трудно восстановить, потому что они могут меняться по ходу работы объекта, а доступа из вне к ним нет. Т.е. по сути, случаи, в которых нужно делать eval для сборки аргументов конструктора, высосаны из пальца.
Вот небольшой пример:
В этом случае, после сериализации/десериализации объекта, метод getCapitol будет работать неправильно, т.к. связанная с ним переменная isCapitol обнулится. Но если использовать текущий метод десериализации, то она сохранится.