Обсуждение:Collections

Близимся к завершению?

• Вроде как с Collections и все. Посмотрите, пожалуйста. Замечания к комментариям, оформлению, может быть ошибки.
  И Println в стеках и очередях выбрасывать или можно оставить в прикладных целях?— Juliet 20:00, 23 апреля 2009 (MSD)

• Println можно оставить.
  На мой взгляд, все-таки этот текст следует разбить на тексты для каждого класса коллекции и в начале сделать оглавление. К каждому тексту прилагать полный файл модуля.
  
  Интерфейс классов следует писать в виде type A = class...end; и не надо по-другому— Admin

• >На мой взгляд, все-таки этот текст следует разбить на тексты для каждого класса коллекции и в начале сделать оглавление. К каждому тексту прилагать полный файл модуля.
  Какой текст?— Juliet 18:13, 27 апреля 2009 (MSD)

Общее

Да, и может лучше Assert'ы заменить на вывод сообщений об ошибках?— Juliet 12:59, 19 апреля 2009 (MSD)

Думаю, не стоит Assert заменять на вывод сообщений об ошибках, т.к.

• это в какой-то степени открывает реализацию,
• может испортить содержимое консоли,
• применение assert-ов - это уже традиция,
• при компиляции версии релиз assert-ы должны убираться, а вот вывод не уберешь.

Хотя, конечно, это будет выглядеть гораздо красивее.

— Saatchi 19:09, 20 апреля 2009 (MSD)

При компиляции версии релиз их убирают, но при этом есть адекватный контроль ошибок. А тут нате вам ошибочку, причем непонятно какую.— Juliet 19:48, 20 апреля 2009 (MSD)

А может лучше исключение генерировать? Они у нас, кстати, в этом семестре будут? — Juliet 20:44, 20 апреля 2009 (MSD)

Исключения - да, надо генерировать вместо Assertов. Надо подключить пространство имен System: uses System;

И потом можно писать:

raise new Exception('Такое-то исключение');

Ну это вообще идеальный вариант! Но я категорически против вывода на консоль!

— Saatchi 18:33, 21 апреля 2009 (MSD)

Леш, придерживайся, пожалуйста, канонического стиля в форматировании. Не есть хорошо, когда все разное.— Juliet 20:40, 21 апреля 2009 (MSD)

Исправил. Полностью согласен. Единственное, мне кажется, стоит определить эти самые требования для будущего.

— Saatchi 21:28, 21 апреля 2009 (MSD)

Может в стеке и очреди заменить Top на Peek? А то несимметрично, в стеке из-за этого поле fTop, а у очереди вообще понятия «вершины» нет
— Juliet 15:06, 23 апреля 2009 (MSD)

Да, править интерфейс из соображений симметрии реализации это сильный ход. Сейчас интерфейсы максимально приближены к (как вы тут где-то выразились) каноническим (разве что Pop должна быть процедурой), и курочить их я бы не стал. — Ulysses 15:16, 23 апреля 2009 (MSD).

Ну и ладно =) — Juliet 20:00, 23 апреля 2009 (MSD)

Мне кажется, что модуль будет болле читаемым, если форматировать так:

Пример  

//STACK ---------------------------------------------

     //Стандартные методы ---------------------------
          {Стандартный конструктор}
          constructor Stack<DataType>.Create;
          begin
            fTop := nil;
          end;
           
          {Создает стек, заполненный элементами, переданными в качестве параметров}
          constructor Stack<DataType>.Create(params xDatas: array of DataType); 
          begin
            fTop := nil;
            for var i := 0 to xDatas.Length - 1 do
              Push(xDatas[i]);
          end;
           
         ...
      
     //Вывод содержимого ---------------------------
          {Выводит подряд содержимое стека
              delim — разделитель между элементами в строке
              elemsInLine — количество элементов, выводимых в одной строке}
          procedure Stack<DataType>.Print(delim: string; elemsInLine: integer);
          begin
            ...
 
 
 
//QUEUE ---------------------------------------------

     //Стандартные методы --------------------------------
          {Создает пустую очередь}
          constructor Queue<DataType>.Create;
          begin
            head := nil;
            tail := nil;
          end;
           
          ...

Комментарии

Мне кажется, много очевидных комментариев, например

{Конструктор}
constructor Stack<DataType>.Create;

  if IsEmpty then
  begin
    head := new SingleNode<DataType>(x, nil);
    tail := head;
  end
  else  // if not IsEmpty

Да, пожалуй. Еще не нравится

//============================================INTERFACE========================================

Я бы вообще убрал

Admin 22:14, 17 апреля 2009 (MSD)

Да, пожалуй.

Сейчас конструкторов несколько, есть смысл их именовать, только надо подумать, как лучше.— Juliet 22:52, 17 апреля 2009 (MSD)

Еще не нравится
//============================================INTERFACE========================================
Я бы вообще убрал

А IMPLEMENTATION?— Juliet 22:52, 17 апреля 2009 (MSD)

Тоже Admin 22:37, 20 апреля 2009 (MSD)

Сколько модулей?

Нельзя ли разбить модуль на модули STACK, QUEUE, ... и просто их подключать в модуле Collections.
Преимущества:

1. Читаемость и удобство редактирования.
2. Пространство имён и IntelliSense.

— Saatchi 18:36, 16 апреля 2009 (MSD)

Комментарии мне не жалко, можно убрать. Хотя особого вреда не вижу.
Модули.. не знаю. Назначение ж у Collections, если я правильно поняла, вполне определенное, чтоб открывать, читать, и , видимо, сравнивать, а по куче модулей лазить не очень удобно.— Juliet 18:58, 16 апреля 2009 (MSD)

Да, но по огромному модулю лазить тоже не удобно, взять к примеру PABCSystem.

— Saatchi 21:35, 17 апреля 2009 (MSD)

Ну настолько огромным он не будет. 5-6 классов в принципе. Если бы было что-то вроде заголовочного файла, чтобы интерфейс всех в одном месте, а реализация по разным...— Juliet 21:47, 17 апреля 2009 (MSD)

Есть резон и в нескольких модулях. И в одном. Пока не знаю.

По идее, в Collections можно только и писать что

type Stack<T> = StackUnit.Stack<T>;

Но переходить к определению стека придется дважды - вначале в Collections, потом - в Stack, что не есть хорошо

А мне кажется, с заголовочным файлом будет здорово.

— Saatchi 11:34, 18 апреля 2009 (MSD)

Ну да разберемся, пока выделила несколько модулей для удобства чтения плюс к полному.— Juliet 12:22, 19 апреля 2009 (MSD)

DynArray

Что делать с Add, Insert, Delete? На лекции они были написаны для одного элемента, сейчас — в варианте с params. Можно так оставить, или для params надо отдельные методы?
Только если делать отдельные, то имхо, тело лучше оставить таким же, а не вызывать в них n раз соответствующие методы для одного элемента.— Juliet 12:30, 19 апреля 2009 (MSD)

Мне кажется, делайте для одного параметра. Это - учебный модуль. Понятно, мы можем лучше. Admin 22:36, 20 апреля 2009 (MSD)

Еще такой вопрос: для массива делать сортировку?— Juliet 12:32, 19 апреля 2009 (MSD)

Не надо. Сортировка нуждается в сравнении. А в шаблонах это пока для вас сложно. Admin 22:36, 20 апреля 2009 (MSD)