большие процедуры/функции

← →
young_dev (2011-03-30 17:47) [0]

написал процедуру, которая проверяет целостность содержимого определенного файла, получилось порядка 250 строк. нужно ли, с точки зрения организации кода, разбивать большие процедуры/функции? Хотелось бы услышать мнения по этому поводу.

← →
Медвежонок Пятачок © (2011-03-30 17:49) [1]

теперь все сотри что написал, и напиши функцию вместо процедуры.

← →
Дмитрий Тимохов (2011-03-30 17:50) [2]

смотря, что за процедура:
можно и не разбивать.
а можно и разбивать.
иногда нужно разбивать.
иногда просто обязательно.

← →
GanibalLector © (2011-03-30 17:51) [3]

"Совершенный код" Макконнелл

Там есть ответ!

← →
Медвежонок Пятачок © (2011-03-30 17:53) [4]

нужно ли, с точки зрения организации кода

у организации кода нет точки зрения. значит не нужно.

← →
clickmaker © (2011-03-30 17:54) [5]

> нужно ли, с точки зрения организации кода, разбивать большие

Если в процессе написания большой п/ф возникает дежа вю, то надо

← →
Kerk © (2011-03-30 17:54) [6]

Если рассматривать сферическую функцию в вакууме, то разбиение ее на отдельные небольшие функции прежде всего улучшает читаемость кода.

Вместо

function CheckFile: Boolean; begin // Check Header ... 200 строк // Check Body ... 200 строк // Check Footer ... 200 строк end;
лучше будет смотреться
function CheckFile: Boolean; begin CheckHeader; CheckBody; CheckFooter; end;

Если у тебя там есть комментарии (а в 250-строчной функции они скорее всего есть), то это признак того, что код стоит переписать.

← →
Dennis I. Komarov © (2011-03-30 17:55) [7]

> которая проверяет целостность содержимого определенного
> файла, получилось порядка 250 строк

все может быть, но что-то я сомневаюсь в их нужности...

> нужно ли, с точки зрения организации кода, разбивать большие
> процедуры/функции?

зависит от содержимого

← →
Игорь Шевченко © (2011-03-30 17:56) [8]

> лучше будет смотреться

Спорный вопрос

← →
Kerk © (2011-03-30 17:59) [9]

> Игорь Шевченко © (30.03.11 17:56) [8]
>
> > лучше будет смотреться
>
> Спорный вопрос

Ну почему же. Здесь дело не только в группировке кусков кода, но и в напоминании себе (а компилятор проконтролирует), что эти куски логически разделены. С каждым таким куском уже можно работать отдельно, не задумываясь о том, что там выше или ниже будет происходить в данной области видимости.

← →
Игорь Шевченко © (2011-03-30 18:06) [10]

> Ну почему же.

потому что в каждом случае удобно делать в зависимости от случая. В ряде случаев код становится менее удобочитаемым при подобной разбивке.

← →
Kerk © (2011-03-30 18:10) [11]

> Игорь Шевченко © (30.03.11 18:06) [10]
>
> > Ну почему же.
>
> потому что в каждом случае удобно делать в зависимости от
> случая. В ряде случаев код становится менее удобочитаемым
> при подобной разбивке.

Ну это понятно. То были просто общие соображения.

← →
Думкин (с отпуска) (2011-03-30 18:11) [12]

> Kerk © (30.03.11 17:59) [9]

У меня сейчас взаимонепонимание с "тем кто выше". Как раз тут. Он хочет архитекрутить и т.п. Начитался. Бывает.

В итоге простая операция, иногда, превращается, в дикий предподвыверт, лишь бы соответствовать его представлениям "О". Я думаю о смене места работы.

← →
Думкин (с отпуска) (2011-03-30 18:14) [13]

> В ряде случаев код становится менее удобочитаемым при подобной
> разбивке.

Вот. ИНе логичнмы, что еще грустнее.

← →
Kerk © (2011-03-30 18:27) [14]

> Думкин (с отпуска) (30.03.11 18:11) [12]

Любую идею можно довести до абсурда. Чего накинулись? :)

← →
young_dev (2011-03-30 18:31) [15]

Примерно такая процедура.

procedure Items.analyze_file_of_import(const file_name: string; full_analyze: Boolean); var // ... I, prod_status, category_id : Integer; // ... begin // ... for I := 0 to Self.Count - 1 do begin //... // caheck value of field prod_status Fprod_status := Vals[C_PROD_STATUS_NAME]; if not (prod_status in [C_PROD_STATUS_AVAILABLE.. C_PROD_STATUS_NOT_AVAILABLE]) then raise Exception.CreateResFmt(@C_INVALID_PROD_STATUS, [Fprod_status, I]); // check value of field category_id Fcategogy_id := Vals[C_CATEGORY_ID_NAME]; if not is_valid_category(Fcategory_id) then raise Exception.CreateResFmt(@C_INVALID_CATEGORY_ID, [Fcategory_id, I]); // ... // еще порядка 30 аналогичных проверок, код получается около 250 строк // ... end; // ... end;

может для проверки каждого поля сделать отдельные функции, типа:

check_prod_status_val();
check_category_id_val();

← →
Kerk © (2011-03-30 18:33) [16]

В твоем случае похоже и правда нет смысла разбивать это. Лучше не станет. Подумай о том, как можно унифицировать проверки. Если никак, то судьба, значит.

← →
Kerk © (2011-03-30 18:34) [17]

> // check value of field category_id

Такие комментарии в общем-то бессмысленны. И без них видно, что происходит какая-то проверка. А вот в чем смысл проверки - вопрос :)

← →
young_dev (2011-03-30 18:46) [18]

> А вот в чем смысл проверки - вопрос

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

← →
Думкин (с отпуска) (2011-03-30 18:58) [19]

> young_dev (30.03.11 18:31) [15]

Тут я так понимаю, не до скорости. Потому, я бы выделил сущность из цикла. Держать в цикле такой кошмар мне моя отстутсвующая религия - не позволяет. Это первое что приходит в голову. Если у меня не в процедуре, а вцикле будет так - я удавлюсь.

Класс там какой и т.п. И вообще, бррр...

> Kerk © (30.03.11 18:27) [14]
> Любую идею можно довести до абсурда. Чего накинулись? :)

Так доводят же. В реальности. Маконнелла прочитают и начинают добро направо и налево раздавать.

← →
Игорь Шевченко © (2011-03-30 19:10) [20]

> начинают добро направо и налево раздавать.

Чтоб никто не ушел обиженным. Ампутация рук по самую голову очень хорошо помогает в таких случаях.

← →
Pavia © (2011-03-30 19:17) [21]

Судя по всему функция останется такой длиной. Но вот для удобства восприятия можно организовать её в виде таблички.

chek(C_PROD_STATUS_NAME, @check_prod_status_val, @C_INVALID_PROD_STATUS);
chek(C_CATEGORY_ID_NAME, @check_category_id_val, @C_INVALID_CATEGORY_ID);

← →
TUser © (2011-03-30 21:04) [22]

Личное правило: функция должна умещаться на экране. Поэтому экран надо побольше. Но 250 строк все равно надо разбить. Разбил бы я сам или нет - сильно зависит от фазы луны.

← →
Rimma (2011-03-30 21:19) [23]

Лучшее враг хорошего!

← →
palva © (2011-03-30 22:09) [24]

> может для проверки каждого поля сделать отдельные функции

А что, нормальная идея. Особенно, если в дальнейшем планируется добавление новых полей, расширение допустимых диапазонов для отдельных полей... Даже если не планируется, это часто приходится делать.

← →
_Юрий (2011-03-30 22:45) [25]

Если все строго сверху вниз без длинных ветвлений, то разбивать необязательно, можно отформатировать и по другому. Регионами например.

← →
DVM © (2011-03-30 23:23) [26]

> лучше будет смотреться
>
> function CheckFile: Boolean;
> begin
> CheckHeader;
> CheckBody;
> CheckFooter;
> end;

в новых делфи есть такая удобная вещь как регионы - свернуть можно любой кусок кода и все смотреться будет отлично

← →
картман © (2011-03-30 23:30) [27]

> Так доводят же. В реальности. Маконнелла прочитают и начинают
> добро направо и налево раздавать.

> young_dev (30.03.11 18:31) [15]
>
> Примерно такая процедура.
>

> // еще порядка 30 аналогичных проверок, код получается
> около 250 строк

все просто: 30 классов и фабрика

← →
Rouse_ © (2011-03-31 01:08) [28]

> Kerk © (30.03.11 18:34) [17]
> Такие комментарии в общем-то бессмысленны. И без них видно,
> что происходит какая-то проверка.

Да, действительно, зачем?
Открываю первый попавшийся исходник винды, ну например реализацию FLoadDynEmRules, читаю:

/* F L O A D D Y N E M R U L E S */ /*---------------------------------------------------------------------------- %%Function: FLoadDynEmRules %%Contact: daleg Load rules dynamically from a file or a data structure, depending upon #ifdef ----------------------------------------------------------------------------*/ #ifdef DYN_RULES_FROM_STRUCT #include "emruli.oci" #endif /* DYN_RULES_FROM_STRUCT */ int FLoadDynEmRules(void) { int docii; #ifndef DYN_RULES_FROM_STRUCT /* Read opcodes from a disk file */ if (!MsoFReadDynOciRules("em", &docii)) return fFalse; #else /* DYN_RULES_FROM_STRUCT */ /* Get opcodes from a structure */ vlpruls->pociiDynRules = (PV) vrgociiEm; docii = IMaxRg(vrgociiEm, MSOOCII); vlpruls->rgpchDynNames = _rgszEmRulNames; #endif /* !DYN_RULES_FROM_STRUCT */ #define NON_CONST_OCI_VTABLE #ifdef NON_CONST_OCI_VTABLE /* Insert Mso functions into OCI vtable */ if (!MsoFCopyBaseRulRgpfnoci(vpfnociEm)) return fFalse; #endif /* NON_CONST_OCI_VTABLE */ /* Generate rulebase nodes from opcode stream */ return MsoFLoadDynRulesPocii(vlpruls->pociiDynRules, docii, vpfnociEm, vrgocadEm, vrgcbOciArgEm, IMaxRg(vpfnociEm, MSOPFNOCI), DebugElse(vlpruls->rgpchDynNames, pNil)); }

Такие комментарии в общем-то бессмысленны, и без них видно что происходит, но... они есть. Наверное не просто так?

← →
Kerk © (2011-03-31 01:13) [29]

> Rouse_ © (31.03.11 01:08) [28]

Ну если ты не видишь принципиальной разницы между комментариями типа
// caheck value of field prod_status // check value of field category_id
и
/* Read opcodes from a disk file */ /* Generate rulebase nodes from opcode stream */
то я ничем не могу помочь.

← →
Германн © (2011-03-31 01:54) [30]

> Kerk © (31.03.11 01:13) [29]

Есть комментарии и комментарии. И главное в комментариях - это полезность самому автору. (Если он не работает в команде или если его код другие участники команды не смотрят в виду отсутствия производственной необходимости).
Другое дело если требования к комментариям как-то зафиксировано руководителем работ.

← →
Германн © (2011-03-31 02:27) [31]

> Германн © (31.03.11 01:54) [30]
>
>

Да. Забыл указать ещё один вариант. Если речь идет о компоненте/библиотеке, которые поставляются (с исходниками) другим людям, то, конечно, комментарии должны следовать другим правилам.

← →
han_malign (2011-03-31 09:12) [32]

> check_prod_status_val();
> check_category_id_val();

> Держать в цикле такой кошмар мне моя отсутствующая религия - не позволяет.

я бы такую схему предложил для начала
function validate(vals: array of TMyVals, var failField: TMyValEnum): boolean; begin Result:= false; failStage:= C_PROD_STATUS_NAME; Fprod_status := Vals[failField]; if not (prod_status in [C_PROD_STATUS_AVAILABLE..C_PROD_STATUS_NOT_AVAILABLE]) then exit; failField:= C_CATEGORY_ID_NAME; ................... Result:= true; end;
...
for I := 0 to Self.Count - 1 do if( not validate(vals, stage) )then raise Exception.CreateResFmt(rgsErrorMsgFmts[stage], [vals[stage], I]);

затем, в контексте Pavia © [21], подумал бы о (при условии что нет проверок контекстно зависимых от других полей)
function validateField(Field: TValEnum; const Value): boolean; begin Result:= false; case(Field)of C_PROD_STATUS_NAME: Result:= ...; ... else raise Exception.CreateResFmt("Забыл добавить ветвление для %d", [Field]); end{case(Field)}; end{function validateField};

теперь самой длинной(но уже раза в два короче) функцией будет validateField, зато применяться она может в любом месте - включая заполнение полей пользователем - а вся остальная логика становится короткой и ясной...

← →
han_malign (2011-03-31 09:17) [33]

(продолжение):
for I := 0 to Self.Count - 1 do for stage:= low(stage) to high(stage) do if not validateField(stage, vals[stage])then raise Exception.CreateResFmt(rgsErrorMsgFmts[stage], [vals[stage], I]);

← →
И. Павел © (2011-03-31 09:19) [34]

Не бывает больших процедур, бывает маленькое разрешение экрана :) А вообще - разбиение кода на процедуры - это палка о двух концах, т.к. нужно учитывать еще такое понятие как связность кода.

← →
han_malign (2011-03-31 09:30) [35]

> такое понятие как связность кода

- side-эффекты(не знаю как этот термин на русский перевести) глобального контекста(тут забыл, там недоперепрятал)...

З.Ы. А целостность полей лучше проверять и подсвечивать при вводе...

← →
Игорь Шевченко © (2011-03-31 10:22) [36]

> З.Ы. А целостность полей лучше проверять и подсвечивать
> при вводе...

Марксизм не догма, а руководство к действию

← →
Rouse_ © (2011-03-31 11:34) [37]

> Kerk © (31.03.11 01:13) [29]
> Ну если ты не видишь принципиальной разницы между комментариями

Нет не вижу, лучше оставить сто бессмысленных для Керка коментариев, но в последующем полезных для другово, чем не делать их вообще. Если ты не понимаешь для чего вообще нужны коментарии, даже бесполезные по твоему мнению, то я ничем не могу помочь.

← →
DiamondShark © (2011-03-31 11:45) [38]

> > может для проверки каждого поля сделать отдельные функции

> А что, нормальная идея. Особенно, если в дальнейшем планируется
> добавление новых полей, расширение допустимых диапазонов
> для отдельных полей...

Тогда дескрипторы полей сделать классами, собрать в коллекцию, набор данных из какого-то невнятного массива превратить в структурированный объект, с унифицированным доступом к строкам и полям, со встроенной автоматической валидацией...

Ещё несколько лёгких движений напильником, и готов самопильный датасет.
Вот только остаётся не при делах регенерирующий реактор на субтепловых нейтронах.

← →
Kerk © (2011-03-31 13:16) [39]

Удалено модератором

← →
Думкин © (2011-03-31 13:25) [40]

Удалено модератором

← →
Mystic © (2011-03-31 13:32) [41]

> Kerk © (30.03.11 17:54) [6]

function CheckFile: Boolean; begin CheckHeader; CheckBody; CheckFooter; end;

Это самый простой случай, чаще возникает ситуация, когда это заменяется либо на

function CheckFile: Boolean; var Ctx: TCheckFileContext; begin CheckHeader(Ctx); CheckBody(Ctx); CheckFooter(Ctx); end;

либо на

class function TFileChecker.Check: Boolean; var FileCheckerInstance: TFileChecker; begin FileCheckerInstance := TFileChecker.Create(); try FileCheckerInstance.CheckHeader(Ctx); FileCheckerInstance.CheckBody(Ctx); FileCheckerInstance.CheckFooter(Ctx); finally FileCheckerInstance.Free; end; end;

← →
Rouse_ © (2011-03-31 13:45) [42]

Удалено модератором

← →
Rouse_ © (2011-03-31 13:46) [43]

Удалено модератором

← →
Kerk © (2011-03-31 13:49) [44]

Удалено модератором

← →
Kerk © (2011-03-31 13:50) [45]

Удалено модератором

← →
KilkennyCat © (2011-03-31 14:19) [46]

> > лучше будет смотреться
> >
> > function CheckFile: Boolean;
> > begin
> > CheckHeader;
> > CheckBody;
> > CheckFooter;
> > end;

Вы не видели, наверное, АS3.
для любой фигни - функция.
новый класс - новый файл.
вообщем, любое телодвижение - функция, файл.
это по ихней идеологии.
в результате ОЧЕНЬ удобно. слов нет. пока сквозь гору и кучу этого продерешься - забудешь чего хотел.
И если в Делфи сотня едитов с персональным одинаковым обработчиков это признак идиотизма, то там это в порядке вещей.
Хотя можно писать и нормально.

← →
Kerk © (2011-03-31 15:03) [47]

> KilkennyCat © (31.03.11 14:19) [46]

AS3 - это флеш? Наверно, именно поэтому небольшой баннер на забытой вкладке браузера может отожрать совершенно любое количество памяти :))

← →
Компромисс (2011-03-31 15:34) [48]

KilkennyCat

Вам нужно научиться писать/использовать компоненты. AS3 богаче Delphi по возможностям. Чего только один ClassFactory стоит или first-class functions

← →
картман © (2011-03-31 17:59) [49]

> AS3 богаче Delphi по возможностям.

а html - богаче AC3, ага

← →
Kerk © (2011-03-31 18:07) [50]

> картман © (31.03.11 17:59) [49]

Ну так. На Delphi вообще пришлось бы код писать, чтоб картинку на экран вывести, а в html пишешь <img src=""> и все, готово :))

← →
Компромисс (2011-03-31 18:11) [51]

картман

Это к чему вообще? Flex/AS3 - полноценный ООЯ, никакие html и рядом не стоят. Даже int является объектом, например.
Если человек вместо того, чтобы вынести повторяющийся функционал в компонент (конечно, это же будет отдельный файл, которые он так не любит!), дублирует обработчики, он ССЗБ

← →
картман © (2011-03-31 18:16) [52]

> Это к чему вообще?

я не согласился с

> AS3 богаче Delphi по возможностям.

← →
Компромисс (2011-03-31 18:26) [53]

я не согласился с

Вы же не знаете Flex/AS3, насколько я понимаю. Как же Вы можете судить в таком случае?
В Flex/AS3 есть много очень интересных фишек, начиная с Bindable (при изменении свойства модели все view, которые его используют, автоматически обновятся без всякого кода) и заканчивая операторами (не путать с синтаксическим сахаром!), которые позволяют работать с массивами, коллекциями, Dictionary и просто объектами одинаковым образом, благодаря тому, что эти объекты внутренне предствалены похожим образом
for each(var item:Object in items){
...
}

где items может оказаться (в runtime!) и Array, и ArrayCollection, и Object, и Dictionary.
А уж reflexion вообще сказка, например this["my" + i] обратится к свойству my1, если i=1. причем my1 может быть как var, так и get function, то есть инкапсуляция поддерживается идеально - переменную всегда можно поменять на пару get/set если необходимо, а клиенты ничего не заметят.

← →
Kerk © (2011-03-31 18:29) [54]

> Компромисс (31.03.11 18:26) [53]

Что-то вообще ничего особенного в перечисленном не заметил.
Кроме, пожалуй:

> например this["my" + i] обратится к свойству my1, если i=1.
> причем my1 может быть как var, так и get function

Но это обычная фишка для скриптовых языков. В Delphi этого хаоса к счастью нет.

Вообще, не видно какой-то связи между языком и Bindable с ClassFactory. Ты думаешь, в Delphi никто фабриками классов не пользуется, раз приводишь это как мегафичу языка(почему-то)?

> например this["my" + i] обратится к свойству my1, если i=1.

ночной кошмар программиста

← →
delphimaster (2011-03-31 18:53) [57]

Удалено модератором

> Компромисс (31.03.11 18:26) [53]
>
> я не согласился с
>
> Вы же не знаете Flex/AS3, насколько я понимаю. Как же Вы
> можете судить в таком случае?

не знаю. Но в качестве примера я привел именно хтмл, чтобы указать, что узко заточенный язык, коим является AS3 не в состоянии конкурировать с традиционными по всем направлениям, ведь тут:

AS3 богаче Delphi по возможностям.

написано о возможностях вообще, а не о рюшечках, вот что могло подразумеваться - другой вопрос.

В [53] - только они, симпатишные рюшечки.

> Игорь Шевченко © (31.03.11 18:45) [56]
> ночной кошмар программиста

Ночной кошмар -- это монстрики 60-х годов прошлого века, вроде паскаля и си++.

> delphimaster (31.03.11 18:53) [57]
> кому понадобятся такие извращения

Самый примитивный пример: сериализация объектов.

DiamondShark © (31.03.11 19:04) [59]

Видите ли, Дима, по моему скромному мнению, кошмар в том, что диагностика ошибок с времени компиляции переносится на время выполнения.

> диагностика ошибок с времени компиляции переносится на
> время выполнения.

Как, например, при инициализации формы из DFM, или в конструкциях вида
query1.FieldByName("KodTovara")

Видите ли, Игорь, современные программы строятся не столько на встроенных средствах языка (ну сколько в том Паскале встроенных средтв-то?!), сколько на библиотеках и фреймворках.
И вот тут-то ВНЕЗАПНО выясняется, что программы состоят из ошибок, перенесённых на время исполнения, чуть менее, чем полностью.
А если солдафонская кондовость языка всё равно не избавляет от переноса ошибок на время выполнения, то зачем плац ломом подметать? Из верности заветам Ильича?

DiamondShark © (31.03.11 19:37) [62]

> Как, например, при инициализации формы из DFM, или в конструкциях
> вида
> query1.FieldByName("KodTovara")

Кто бы спорил. Правда насчет инициализации формы не совсем понял.

> Из верности заветам Ильича?

Отнюдь. Программы пишут люди, людям свойственно ошибаться, а так как с покрытием тестами дела обстоят не так радужно, как хотелось бы, то переложить чуть больше работы по выявлению ошибок на компилятор всегда полезно. Он железный и быстрый.

← →
Компромисс (2011-03-31 20:29) [64]

Kerk © (31.03.11 18:29) [54]

Это не хаос. Я обычно на Flex пишу как на Delphi/Java, со строгой типизацией (компилятор имеет соответствующую настройку, включенную по умолчанию). Но бывает полезным и упрощенный reflection (как и в Delphi).

картман © (31.03.11 19:03) [58]

написано о возможностях вообще, а не о рюшечках, вот что могло подразумеваться - другой вопрос.

Я писал именно о том, чем возмутился KilkennyCat © (31.03.11 14:19) [46]
То есть именно в ООП и компонентно-ориентированном программировании (особенно UI) возможности AS3/Flex выше. Конечно, для работы с БД, например, возможности у AS3/Flex вообще никакие :)

Игорь Шевченко © (31.03.11 18:45) [56]

Никто не мешает использовать my1 без всяких извращений, так компилятор даже типы проверять будет, причем не хуже, чем в Delphi

> Компромисс (31.03.11 20:29) [64]

> Я писал именно о том, чем возмутился KilkennyCat © (31.
> 03.11 14:19) [46]

тады ой.

> DiamondShark © (31.03.11 19:04) [59]
>
> Ночной кошмар -- это монстрики 60-х годов прошлого века,
> вроде паскаля и си++.

можно пример некошмарного?

Во Флексе и АС3 все делается, извиняюсь, через заднее место.
Некоторые фишки, позаимственные у Явы - все его богатство.
Эзотерические языки тоже могут вызывать восхищение. Попробуйте использовать на практике.
Может быть, АС3 и полноценный ООЯ.
Но в сочетании с ущербной(неудобной) средой разработки и конечной целью - мультик, баннер, игрушка и прочая фигня - он такой все только усложняет.

Говорите, использовать все его богатство компонент и пр.? Ну, видел я такие работы. Тяжелые, жрущие ресурсы, тормозящие.

АС2 и то был практичнее, хотя бы несквозной событийностью и автоматическим удалением всего связанного с объектом, при удалении оного.

Удел флэша - мультики и игры. Там ему надо было и оставаться, развиваясь в 3D, упрощая труд анимации и пр. А не пытаться стать еще одним аля дотнетом.
За двумя зайцами погонишься - от обоих по шее и получишь.

> KilkennyCat © (01.04.11 01:10) [67]
> Эзотерические языки тоже могут вызывать восхищение. Попробуйте
> использовать на практике.

Ну я использовал на практике JavaScript, это очень близкий родственник ActionScript. Фактически, различаются только библиотекой встроенных объектов.
Довольно большое ASP приложение (дотнета ещё не было в природе), причём, сначала был напилен свой фреймворк.
Язык действительно богаче дельфи. Главное -- не поддаваться стереотипам.

А из среды разработки у меня был только нотепад.

> JavaScript, это очень близкий родственник ActionScript.

http://ejohn.org/files/ecma-cloud.png

> А из среды разработки у меня был только нотепад.

да. а я когда-то писал в машкодах. нотепад был бумажный.
и что?
питекантропы вообще без компов жили, но времена меняются.
с нотепадом сейчас не везде далеко пойдешь.

> KilkennyCat © (01.04.11 03:18) [69]
> http://ejohn.org/files/ecma-cloud.png

Рисовал метадоновый наркоман, попавший по ошибке на измену от шишек.

По схеме Microsoft JScript и Mozilla JavaScript -- пипец какие разные языки.
Встретишь Джона -- передай, чтоб траву с алкоголем не мешал.

> с нотепадом сейчас не везде далеко пойдешь.

У тебя сегодня профессиональный праздник, что-ли?

← →
Компромисс (2011-04-01 13:40) [71]

KilkennyCat © (01.04.11 01:10) [67]

Как все запущено.

Я уже много лет только бизнес приложения на Flex пишу и ничего больше, ни игр, ни баннеров, ни мультиков.
Вот тут например можно посмотреть грид, который сам группирует данные по определенным полям и отображает в виде дерева. Причем элементарно добавлять in-place editor и прочие штуки, которые должны быть знакомы любому delphi-разработчику.
http://help.adobe.com/ru_RU/FlashPlatform/reference/actionscript/3/mx/controls/AdvancedDataGrid.html?filter_flex=4.1&filter_flashplayer=10.2&filter_air=2.6#inc ludeExamplesSummary

AS3 ничем не хуже AS2, он тоже автоматически освобождает память от объектов, которые более недоступны. Точно так же, как в JVM.

ЗЫ. Я не умею делать ни мультики, ни презентации. Даже не знаю, в чем они делаются :) Если мне нужно какой-то эффект, достаточно программынй средств, типа showEffect="{Fade}" и при появлении элемент будет появляться достаточно красиво, а hideEffect="{WipeRight}" визуально сотрет элемент слева направо.

> Компромисс (01.04.11 13:40) [71]

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

> AS3 ничем не хуже AS2, он тоже автоматически освобождает
> память от объектов, которые более недоступны.

хмм... насколько я помню, это "автоматически" происходит не всегда, когда надо, невозможно инициировать работу сборщика мусора когда хочется. или ошибаюсь?
по крайней мере, по сжиранию ресурсов картина наблюдалась именно такая.

← →
Компромисс (2011-04-04 10:44) [74]

KilkennyCat © (02.04.11 02:44) [72]

но все-таки сомневаюсь, что бизнес-приложения там столь эффективны и в плане работы, и в плане разработки.

В плане разработки получается быстрее, чем в Delphi. В плане эффективности, конечно, в Delphi эффективнее (при прочих равных условиях).

насколько я помню, это "автоматически" происходит не всегда, когда надо, невозможно инициировать работу сборщика мусора когда хочется. или ошибаюсь?

Нет, не ошибаетесь. Но наже в Java рекомендуют крайне осторожно использовать явный вызов сборщика мусора.

Сжирание ресурсов зависит от качества кода. Если загружать на клиента миллионы записей, то будут проблемы. Мы в таких случаях динамическую загрузку используем.

> хмм... насколько я помню, это "автоматически" происходит
> не всегда, когда надо,

Твоё "надо" и "надо" менеджера памяти -- это разные нады.
Твоё никому не интересно, потому что в 99.666% случаев необосновано и вредно.

> невозможно инициировать работу сборщика мусора когда хочется.
> или ошибаюсь?

Ты так говоришь, будто в этом есть что-то плохое.

> по крайней мере, по сжиранию ресурсов картина наблюдалась
> именно такая.

У дурака в руках и член -- стекло: заставь дурака дрочить, он и член разобьёт и руки порежет.

> KilkennyCat © (05.04.11 08:46) [76]

Докопаться до "эзотерических", как ты выразился, языков, что там менеджер памяти напрямую нельзя вызвать, -- это по глубокомысленности близко к претензиям, например, к SQL, что там нельзя окна рисовать.

Так что ты хорошенько подумай, у кого действительно бред.

DiamondShark © (05.04.11 10:32) [77]

> близко к претензиям, например, к SQL, что там нельзя окна
> рисовать.
>

кстати, да!

но уже все устарело и поменялось: пока мы грызлись, я работал круглые сутки с АS3.... У меня теперь претензии к Делфи :)
Так что, приношу свои извинения.

большие процедуры/функции Найти похожие ветки