Сообщение Re: Еще по Nullable/Optional от 18.12.2014 20:45
Изменено 18.12.2014 20:48 NeoCode
Еще один вопрос — по реализации.
Допустим, язык программирования для ссылочных типов будет поддерживать опциональность естественным путем — для любого ссылочного типа ссылка на NULL это None.
Для типов, представленных по значению, естественно должна поддерживаться внешняя реализация optional<T> — полностью включающая поля класса T и дополнительное поле тега, которое равно None или Some. Эта реализация должна быть полностью совместима со ссылками на null (в плане сравнения объектов, поведения, преобразования одного представления в другое и т.п.)
Но потенциально есть еще одна возможность. Можно добавить в язык программирования поддержку "none-конструктора". Это специальный конструктор объекта, который конструирует объект с внутренним состоянием, которое для этого класса объектов считается невалидным.
С одной стороны вроде удобно (не нужно дополнительных оберток, памяти на них), но с другой — непонятно во что это выльется. Ведь можно в программе явно (без none-конструктора) создать такой объект простым присваиванием полей. И как с ним работать дальше? По идее, с ним нельзя работать дальше, т.к. формально он равен "none", и нужно сразу же выбрасывать исключение.
Допустим, язык программирования для ссылочных типов будет поддерживать опциональность естественным путем — для любого ссылочного типа ссылка на NULL это None.
Для типов, представленных по значению, естественно должна поддерживаться внешняя реализация optional<T> — полностью включающая поля класса T и дополнительное поле тега, которое равно None или Some. Эта реализация должна быть полностью совместима со ссылками на null (в плане сравнения объектов, поведения, преобразования одного представления в другое и т.п.)
Но потенциально есть еще одна возможность. Можно добавить в язык программирования поддержку "none-конструктора". Это специальный конструктор объекта, который конструирует объект с внутренним состоянием, которое для этого класса объектов считается невалидным.
С одной стороны вроде удобно (не нужно дополнительных оберток, памяти на них), но с другой — непонятно во что это выльется. Ведь можно в программе явно (без none-конструктора) создать такой объект простым присваиванием полей. И как с ним работать дальше? По идее, с ним нельзя работать дальше, т.к. формально он равен "none", и нужно сразу же выбрасывать исключение.
Re: Еще по Nullable/Optional
Еще один вопрос — по реализации.
Допустим, язык программирования для ссылочных типов будет поддерживать опциональность естественным путем — для любого ссылочного типа ссылка на NULL это None.
Для типов, представленных по значению, естественно должна поддерживаться внешняя реализация optional<T> — полностью включающая поля класса T и дополнительное поле тега, которое равно None или Some. Эта реализация должна быть полностью совместима со ссылками на null (в плане сравнения объектов, поведения, преобразования одного представления в другое и т.п.)
Но потенциально есть еще одна возможность. Можно добавить в язык программирования поддержку "none-конструктора". Это специальный конструктор объекта, который конструирует объект с внутренним состоянием, которое для этого класса объектов считается невалидным.
С одной стороны вроде удобно (не нужно дополнительных оберток, памяти на них), но с другой — непонятно во что это выльется. Ведь можно в программе явно (без none-конструктора) создать такой объект простым присваиванием полей. И как с ним работать дальше? По идее, с ним нельзя работать дальше, т.к. формально он равен "none", и нужно сразу же выбрасывать исключение.
Также, если объект держал какие-то ресурсы, и вдруг "случайно" стал none, ресурсы остались неосвобожденными и пропали? В общем фигня получается.
Допустим, язык программирования для ссылочных типов будет поддерживать опциональность естественным путем — для любого ссылочного типа ссылка на NULL это None.
Для типов, представленных по значению, естественно должна поддерживаться внешняя реализация optional<T> — полностью включающая поля класса T и дополнительное поле тега, которое равно None или Some. Эта реализация должна быть полностью совместима со ссылками на null (в плане сравнения объектов, поведения, преобразования одного представления в другое и т.п.)
Но потенциально есть еще одна возможность. Можно добавить в язык программирования поддержку "none-конструктора". Это специальный конструктор объекта, который конструирует объект с внутренним состоянием, которое для этого класса объектов считается невалидным.
С одной стороны вроде удобно (не нужно дополнительных оберток, памяти на них), но с другой — непонятно во что это выльется. Ведь можно в программе явно (без none-конструктора) создать такой объект простым присваиванием полей. И как с ним работать дальше? По идее, с ним нельзя работать дальше, т.к. формально он равен "none", и нужно сразу же выбрасывать исключение.
Также, если объект держал какие-то ресурсы, и вдруг "случайно" стал none, ресурсы остались неосвобожденными и пропали? В общем фигня получается.