Ответ
G_Z 17.10 03:25
/ 17.10 03:26
Текущая реализация мне кажется более целостной.
Я, возможно, чего-то недопонимаю, но при этом:
1. главный конструктор, привычный по всем другим классам, не позволяет создать массив литерально в коде, а занимается только приведением других типов к массиву — есть мнение, это задача не «главного» конструктора, а какого-нибудь
array::parse;
2. нет простого способа создать массив нестрок.
По-моему создание массива в коде — самая частая операция.
И написать
^array::create(1;2;3)[d;e] — первое, что приходит в голову по аналогии с
hash::create и
table::create.
В других языках для создания массива не нужно сначала создать массив (!) или хеш-таблицу.
Даже простой
$a[^array::create[1]] сейчас приводит к ошибке
param must be array or must have hash representation, при этом
$a[^array::create[]] — не приводит.
предложенный вариант прямой путь к минусам, от которых мы страдали с хешами (к счастью, уже победили).
И при этом нет простого способа слияния хешей в коде — каждый раз пляски с копированием через
hash::create и добавлением ключей к копии, чтобы не поймать
hash may not be overwritten with hash, store it to variable instead.
может еще лучше варианты будут
Моё мнение:
1.
array::create должен позволять литерально создавать массивы в коде — это действительно та операция, которую заявляет имя конструктора;
2. копирующий конструктор должен называться иначе;
array::parse — близкий по смыслу вариант, но по опыту с
json::parse подразумевает десериализацию, что сбивает с толку, пока ничего лучше избитого
array::init в голову не пришло.
