Условные обозначения для повторений ES6?

Question

Я автор graph datastructure library для JavaScript. Я в настоящее время ES6-ifying библиотеки.

Я также хочу сделать его более удобным для программистов ES6, что означает реализацию iterable protocol. Но граф имеет несколько вещей для перебора и множественные способы их итерации (вершины, ребра, преемники, предшественники, вершины в топологическом порядке и т. Д.)

У меня есть идея о том, как создать этот интерфейс, но Я бы хотел следовать существующим соглашениям, если они существуют. Вот пример того, как я мог бы сделать часть «вершин»:

class JsGraph { 
    // ... 
    get vertices() { 
     return { 
      _graph: this, 
      get length() { return this._graph._vertexCount }, 
      *[Symbol.iterator]() { 
       var keys = Object.keys(this._graph._vertices); 
       for (let i = 0; i < keys.length; ++i) { 
        yield [keys[i], this._graph._vertices[keys[i]]]; 
       } 
      } 
     }; 
    } 
    // ... 
} 

Если есть какие-либо existng конвенции я, вероятно, следует следовать (или какие-либо проблемы с этим кодом), ваша обратная связь была бы оценена.

Answer 1

Вы можете получить вдохновение от структур данных ES6 Map и Set. Они предоставляют несколько методов для получения разных итераторов: .values(), .keys() и .entries(). Их метод @@iterator по умолчанию равен entries или values соответственно.

Я не знаю других существующих конвенций, я думаю, они должны будут сформироваться.

какие-либо проблемы с этим кодом

Во-первых, я не уверен, является ли добытчик vertices, который возвращает такой объект является хорошей идеей. Я бы предпочел сделать

get vertexCount() { … } 
vertices*() { … } 

но это будет в основном сводиться к предпочтению. Ваш текущий код не так эффективен, потому что он создает две функции при каждом доступе , вы можете улучшить это с помощью прототипов, если увидите необходимость (class VertexIterator {…}?).

Во-вторых, итераторы по изменяемым данным являются областями, которые могут быть реализованы, поскольку они могут измениться при зацикливании. Вы должны знать об этом и выбирать стратегию (что делает ваши структуры неизменяемыми, вероятно, не может быть и речи). Например, метод MapIterator next указан в «», чтобы определить количество элементов каждый раз, когда он оценивается. ». Аналогично, для перечислений объектов (for in) существует правило, что удаленные свойства никогда не должны появляться (если они еще не перечислены до их удаления), и, конечно, никакое свойство не может быть перечислимо дважды. Тем не менее, им явно разрешено быть непоследовательными относительно ключей, которые добавляются во время выполнения, не даются гарантии о том, появляются ли они в перечислении или нет.