Наткнулся на интересное поведение в D2010

← →
Ega23 © (2010-12-27 15:27) [0]

type TMyType1 = class (TObject) strict private type TMyEnum = (meA, meB, meC); end; TMyType2 = class (TObject) strict private type TMyEnum = (meA, meB, meC); end;

[Error] Unit2.pas(17): E2004 Identifier redeclared: "meA"

← →
12 © (2010-12-27 15:30) [1]

> Unit2.pas(_17_):

:)

← →
Ega23 © (2010-12-27 15:32) [2]

Н-да, 5 баллов!
И всё-таки...

← →
Kerk © (2010-12-27 15:37) [3]

В QC пиши, тут-то какой смысл мусолить.

← →
tesseract © (2010-12-27 15:41) [4]

> [Error] Unit2.pas(17): E2004 Identifier redeclared: "meA"

Вроде правильно пишет. Надо тип объявить. А то у тебя реально два объекта с одинаковыми идентификаторами.

← →
Ega23 © (2010-12-27 15:46) [5]

> Вроде правильно пишет. Надо тип объявить. А то у тебя реально
> два объекта с одинаковыми идентификаторами.

Дык они же private, да ещё и strict
Выходит, что для Enum-а это всё равно в unit-scope находится.
Странно.

← →
oxffff © (2010-12-27 15:48) [6]

> Ega23 © (27.12.10 15:46) [5]
>
> > Вроде правильно пишет. Надо тип объявить. А то у тебя
> реально
> > два объекта с одинаковыми идентификаторами.
>
>
> Дык они же private, да ещё и strict
> Выходит, что для Enum-а это всё равно в unit-scope находится.
>
> Странно.

Приветствую.
IMHO QC.

← →
Ega23 © (2010-12-27 15:52) [7]

> Приветствую.

Взаимно.

> IMHO QC.

Ну вот хотелось бы сначала обсудить, дабы на QC дураком не выглядеть.

← →
tesseract © (2010-12-27 15:52) [8]

> Дык они же private, да ещё и strict

Имена-то у них не Private и не Strict. Объяви перечисляемый тип и используй как поле. Или компилятор должен на ходу выяснять в момент присваивания какой из перечисляемых типов с одинаковым именем имеется в виду?

← →
Kerk © (2010-12-27 15:53) [9]

> tesseract © (27.12.10 15:52) [8]
>
> Или компилятор должен на ходу выяснять в момент присваивания какой из
> перечисляемых типов с одинаковым именем имеется в виду?

Чего ему выяснять, если у них scope не пересекается?

← →
tesseract © (2010-12-27 15:58) [10]

> Чего ему выяснять, если у них scope не пересекается?

Выходит область имен у них все-же пересекается. Компилятор назначает каждому перечисляемому типу набор внутренних ID. При смене ID собственно он и ругается. Баг это или не баг в данном режиме не понятно и чего-бы общий тип не задать тож неясно.

← →
Kerk © (2010-12-27 16:00) [11]

> tesseract © (27.12.10 15:58) [10]
>
> > Чего ему выяснять, если у них scope не пересекается?
>
> Выходит область имен у них все-же пересекается.

Выходит, пересекается. В этом и баг :)

← →
oxffff © (2010-12-27 16:01) [12]

> Ega23 © (27.12.10 15:52) [7]
>
> > Приветствую.
>
> Взаимно.
>
> > IMHO QC.
>
> Ну вот хотелось бы сначала обсудить, дабы на QC дураком
> не выглядеть.

А ты прав.

Довод за QC

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

Довод против QC

У компилятора нет возможности выяснить что имел программист под meA.
Либо необъявленный идентификатор, либо действительную активную лексему. То есть что имел ввиду программист TMyType1.meA или TMyType2.meA? Это трудноуловимый момент.

← →
tesseract © (2010-12-27 16:06) [13]

> Выходит, пересекается. В этом и баг :)

Объявление перечисляемых типов не входят в определение strict и private - это не имена процедур и полей. Они собственно и скрываются и видны не будут. А вот объявление типа будет неявно все равно вынесено - и получается что получается. ID будут пересекаться.

← →
oxffff © (2010-12-27 16:12) [14]

> tesseract © (27.12.10 16:06) [13]
>
> > Выходит, пересекается. В этом и баг :)
>
>
> Объявление перечисляемых типов не входят в определение strict
> и private - это не имена процедур и полей.

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

← →
Ega23 © (2010-12-27 16:20) [15]

> и чего-бы общий тип не задать тож неясно.

Ситуация простая. Пишу серию тестов, под каждый - свой парсер, ну, будем считать, HTML-документа.
В конечном итоге, по результатам тестов, останется один парсер.
Соответственно, надо было сделать некое множество HTML-тэгов, встретив которые парсер будет что-то там делать. Выносить это дело "наверх" не хочется, ибо по-идее, это сугубо внутренняя логика парсера.
Ну и получилось. Один парсер, в нём перечислимый тип. Другой парсер, в нём такой же перечислимый тип, только чуть-чуть отличается по набору. У обоих есть TagType ttNone (служебный).
Ну вот и наткнулся на такое поведение.

← →
Ega23 © (2010-12-27 16:26) [16]

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

Проверил.

TMyType1 = class // strict private type // TMyEnum = (meA, meB, meC); strict private const c_MyConst = 1; end; TMyType2 = class // strict private type // TMyEnum = (meA, meB, meC); strict private const c_MyConst = 1; end;

Всё отлично, всё на ура скомпилялось.

← →
tesseract © (2010-12-27 16:30) [17]

> Всё отлично, всё на ура скомпилялось.

Дык и должно. Ты не определяешь же константы meA. Попробуй их объявить как приватные константы и запихнуть в Enum. Так должно прокатить при использовании в приватах класса.

← →
Ega23 © (2010-12-27 16:37) [18]

> Дык и должно. Ты не определяешь же константы meA. Попробуй
> их объявить как приватные константы и запихнуть в Enum.
> Так должно прокатить при использовании в приватах класса.

ээээ...
Я тебя не понял.
Код давай. :)

← →
oxffff © (2010-12-27 16:42) [19]

> Ega23 © (27.12.10 16:26) [16]
>
> > Почему не входят. Определение типа включает в себя область
>
> > допустимых значений констант-лексем, которые действительны
>
> > в указанной области и которые лишены смысла вне его. IMHO.
>
> >
> > То есть встретив выражение MeA можно однозначно установить
>
> > вид, тип этого выражения.
>
>
> Проверил.
>
> TMyType1 = class
> // strict private type
> // TMyEnum = (meA, meB, meC);
> strict private const
> c_MyConst = 1;
> end;
>
> TMyType2 = class
> // strict private type
> // TMyEnum = (meA, meB, meC);
> strict private const
> c_MyConst = 1;
> end;
>
>
>
> Всё отлично, всё на ура скомпилялось.

Все зависит от реализации компилятора. и аналогия не совсем прямая.
Поскольку в данном случае имя является косвенным обращением к значению. В отличии от прямого обращения к значению meA.

← →
tesseract © (2010-12-27 17:18) [20]

Дуим ду :
strict private const meA = 1; meB = 2; meC = 3; strict private type TMyEnum = (meA, meB, meC);

Это эмпирика, но может прокатить.

← →
Alkid © (2010-12-27 19:43) [21]

Вопрос на засыпку: а что написано про это в спецификации языка?
;)

← →
Alx2 © (2010-12-27 21:08) [22]

Ого, как много воды утекло. И это такой Delphi теперь? Аж strict private? Эдакая "частная персональная страница" Еще пяток лет забью на предменую область и совсем все забуду. Зато, наверняка будут монстры типа
strict public privated semiconst
value : metaExtended extends complex fraction over TCalendar;
:)

← →
Ega23 © (2010-12-28 00:13) [23]

> И это такой Delphi теперь?

Давно уже.

← →
Юрий Зотов © (2010-12-28 00:53) [24]

> У компилятора нет возможности выяснить что имел программист под meA.

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

← →
Макс Черных (2010-12-28 02:01) [25]

Юрий Зотов © (28.12.10 00:53) [24]
> Вот и спрашивается - а на фига же искать приключения на
> собственную... голову?

Зачем на свою. :) Мну вот как-то замутил некий реорганизационный момент в куче мале всяких юнитов. Ну и объеденил 3 Олегиных модуля в один. И тут-же вот от этих одинаковых констант перечисляемых компилятор и вошел в ступор. Спрашиваю - это чего и для зачем? Ответ - ХЗ, бум посмотреть. :)

Так что неважно, понимает это компилятор или не понимает, но понятность кода от такого дублирования страдает очень сильно. Вывод - так делать не стоит, ИМХО.

← →
Германн © (2010-12-28 03:22) [26]

> Макс Черных (28.12.10 02:01) [25]
>
> Юрий Зотов © (28.12.10 00:53) [24]
> > Вот и спрашивается - а на фига же искать приключения на
> > собственную... голову?
>
> Зачем на свою. :) Мну вот как-то замутил некий реорганизационный
> момент в куче мале всяких юнитов. Ну и объеденил 3 Олегиных
> модуля в один. И тут-же вот от этих одинаковых констант
> перечисляемых компилятор и вошел в ступор. Спрашиваю - это
> чего и для зачем? Ответ - ХЗ, бум посмотреть. :)

Оригинальная у вас контора. :)
Будь я помоложе...

Не, ну. Должность технического директора у вас не занята?
Точнее она занята и я даже знаю кем. :)

← →
Ega23 © (2010-12-28 07:57) [27]

> Ну и объеденил 3 Олегиных модуля в один. И тут-же вот от
> этих одинаковых констант перечисляемых компилятор и вошел
> в ступор.

Я ж тогда тебя спрашивал: объединять в один модуль или разнести по "один компонент - один юнит". Ты сказал: разнеси, если чё - соберём в один.

← →
Юрий Зотов © (2010-12-28 10:10) [28]

Даже и в случае "один компонент - один юнит" все общие для них типы и константы лучше вынести в отдельный модуль.

← →
Ega23 © (2010-12-28 10:16) [29]

> Даже и в случае "один компонент - один юнит" все общие для
> них типы и константы лучше вынести в отдельный модуль.

Они не общие были. Они были разные, но у некоторых совпадали названия. Поскольку сидели в разных юнитах (поначалу) - было пофиг. Когда Макс начал их в один переносить - вот тут конфликт и произошёл.

← →
Юрий Зотов © (2010-12-28 10:51) [30]

> вот тут конфликт и произошёл.

И очень хорошо, что он произошел. Иначе последствия могли бы быть очень тяжелыми.

← →
oxffff © (2010-12-28 10:55) [31]

> Когда Макс начал их в один переносить - вот тут конфликт
> и произошёл.

:)

← →
DiamondShark © (2010-12-28 11:00) [32]

Клиническая картина ясна: разработчики потеряли чувство языка. Из стройного, логичного и компактного, но при этом мощного языка дельфи превратился в чулан Плюшкина, в который понатаскано рухляди по едиственному принципу: "А шоб было".

← →
Dimka Maslov © (2010-12-28 22:58) [33]

> DiamondShark © (28.12.10 11:00) [32]

Никто ведь и не заставляет пользоваться всей этой шнягой. Пока.

← →
Макс Черных (2010-12-29 00:49) [34]

> разработчики потеряли чувство языка.

Да ну конечно, во всем виноват Путин и ко.
Вот для примера пара кусков кода, аффтор пишет (типа профессионально) более 10 лет:

if ((SR<>"0")and(Mont="0")and(Obor="0")and(Proch="0"))or ((SR="0")and(Mont<>"0")and(Obor="0")and(Proch="0"))or ((SR="0")and(Mont="0")and(Obor<>"0")and(Proch="0")) or ((SR="0")and(Mont="0")and(Obor="0")and(Proch<>"0"))or ((SR="0")and(Mont="0")and(Obor="0")and(Proch="0")) then MultStatRow := false

if (FormNum=1) or (FormNum=2) or (FormNum=14) or (FormNum=4) or (FormNum=22) or (FormNum=24) or (FormNum=17) or (FormNum=18) or (FormNum=13) or (FormNum=21) or (FormNum=20) or (FormNum=26) or (FormNum=23) or (FormNum=25) then

И виноваты в этом тихом ужасе, вестимо, разработчики, и Б.Гейтс, бо он во всем виноват. И Чубайс, который во всем остальном виноват (С ЕБН).

← →
cwl © (2010-12-29 01:03) [35]

> аффтор пишет (типа профессионально) более 10 лет:
много он, интересно, такого за 10 лет написал? %>

← →
Макс Черных (2010-12-29 01:11) [36]

> много он, интересно, такого за 10 лет написал?

Дофига. :) Еще один пример (из многих :( ), синтаксис и комментарии гуру сохранены:

function ChangeSeparatorInStr(str: string): string; var posit, i, l: integer; tmp, s: string; begin posit := pos(",", str); tmp := str; delete(tmp, posit, 1); l := length(str); if (pos("=", trim(str))=1) then //вроде работает, но... for i:=0 to l-1 do begin s := copy(str, i, 1); if s="," then begin tmp := copy(str, i-1, 1); if (tmp<>" ") and ((tmp="0") or (tmp="1") or (tmp="2") or (tmp="3") or (tmp="4") or (tmp="5") or (tmp="6") or (tmp="7") or (tmp="8") or (tmp="9")) then begin tmp := copy(str, i+1, 1); if (tmp<>" ") and ((tmp="0") or (tmp="1") or (tmp="2") or (tmp="3") or (tmp="4") or (tmp="5") or (tmp="6") or (tmp="7") or (tmp="8") or (tmp="9")) then str[i] := "."; end; end; end; Result := str; end;

← →
Германн © (2010-12-29 03:23) [37]

> Макс Черных (29.12.10 00:49) [34]
>
>
> > разработчики потеряли чувство языка.
>

> Макс Черных (29.12.10 01:11) [36]
>
>
> > много он, интересно, такого за 10 лет написал?
>
> Дофига. :) Еще один пример (из многих :( ), синтаксис и
> комментарии гуру сохранены:

А просто навести порядок в своем собственном коллективе, разработать общие нормы для кода что помешало?
Отсутствие нормального технического директора, ИМХО".

Хороший ГенДир - это главное. Без него вообще ничего не будет. Но и без хорошего "технического директора" не обойтись фирме, которая предлагает свои разработки.

← →
TUser © (2010-12-29 04:37) [38]

> Макс Черных (29.12.10 01:11) [36]

Олег не мог такого написать, явно с тырнета скопипастил, халявщик.

← →
Ega23 © (2010-12-29 08:06) [39]

> Олег не мог такого написать

Не-не-не, я так не умею, это не я.
Когда я только на работу пришёл, меня парни напугали кодом этого товарища. Тот на порядок круче приведённого был.

← →
TUser © (2010-12-29 08:09) [40]

IncDay - тоже его произведение?

← →
Ega23 © (2010-12-29 08:12) [41]

Не, IncDay - это отсюда нетленка, с форума. Года 2003-го вроде. После очередного падения - исчезло. А жаль.

← →
Ega23 © (2010-12-29 08:13) [42]

Мне почему-то кажется, что это тонкий вброс кого-то из мастеров был.

← →
Rouse_ © (2010-12-29 13:56) [43]

Это не Олега авторство, но и не самый показательный код, там был примерчик с пятью вложенными with на котором аффтару было очень сложно отлаживаться :)

← →
Kerk © (2010-12-29 14:04) [44]

http://code.progler.ru/view/190

← →
TUser © (2010-12-29 18:12) [45]

Да я просто среагировал на слово "автор" из Макс Черных (29.12.10 00:49) [34], типа автор ветки. Ну и раз там первая фраза правильная, то и остальное верно, очевидно же.

← →
Дмитрий Тимохов (2010-12-31 02:06) [46]

Где то выше Акуличев Димка высказался про потерю чувства языка.
Полностью поддерживаю.

Побаиваюсь я этого монстра. У меня лежит лицензия 2011. Времени нет все заюзать. Но и, как сказал, побаиваюсь - это же в какие сомнения меня он введет, дав мне все эти женерики и анонимные методы, которые еще и работают не всегда корректно.

← →
Владислав © (2010-12-31 10:21) [47]

Волков бояться, в лес не ходить.
Ключевое здесь то, что "не всегда корректно", а в развитии языка ничего плохого нет.

← →
Kerk © (2010-12-31 10:38) [48]

Это не развитие языка. Это попытка сделать его максимально похожим на более популярные языки. Какие-то возможности действительно нужны, какие-то - нет.

Например, в Паскале, а затем Delphi единицей инкапсуляции был модуль. В сях, например, модулей вообще нет, а в Pascal/Delphi есть. Теперь же единицей инкапсуляции пытаются сделать класс - отсюда все эти strict-секции и возможность объявлять типы внутри описания класса. Нельзя сказать, что это плохо вообще в принципе, но это чуждо языку. В Delphi Prism вон, насколько я знаю, вообще нет секций инициализации/финализации в модулях.

Нафига нужен язык, который как C#, но вместо скобочек begin/end мне не очень понятно.

← →
_Юрий (2010-12-31 11:29) [49]

> Kerk © (31.12.10 10:38) [48]

> Нафига нужен язык, который как C#, но вместо скобочек begin/end
> мне не очень понятно.

За язык как таковой не скажу, а сам инструмент
нужен для того, чтобы было на чем писать под Win32.
Под .Net" ом он конечно же не нужен.

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

← →
Anatoly Podgoretsky © (2010-12-31 11:49) [50]

> Kerk (31.12.2010 10:38:48) [48]

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

← →
Kerk © (2010-12-31 12:04) [51]

> _Юрий (31.12.10 11:29) [49]
> нужен для того, чтобы было на чем писать под Win32.

На C++ пиши, там давно все те нужные тебе "новшества" есть.

> Если язык не развивается - он умирает.

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

> Anatoly Podgoretsky © (31.12.10 11:49) [50]

Это другой вопрос. Любую возможность можно неправильно использовать.

← →
Игорь Шевченко © (2010-12-31 12:07) [52]

Kerk © (31.12.10 12:04) [51]

> бездумное копирование

почему бездумное ?

← →
Kerk © (2010-12-31 12:24) [53]

> Игорь Шевченко © (31.12.10 12:07) [52]

Вот не было в Delphi множественного наследования и сейчас нет, слава богу. В свое время эту возможность не стали тупо копировать, а сделали множественное наследование интерфейсов. Т.е. множественного наследования реализации нет, а интерфейсов - есть. И это правильно, я считаю. Кто-то может быть скажет: "фи, ну и пишите дальше свои тонны кода", ничего страшного - напишем.

А теперь возьмем сабжевое объявление типов внутри объявления классов. Оно зачем? Что дальше, объявление переменных по месту использования?

← →
Kerk © (2010-12-31 12:32) [54]

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

← →
Игорь Шевченко © (2010-12-31 12:47) [55]

Kerk © (31.12.10 12:24) [53]

> В свое время эту возможность не стали тупо копировать, а
> сделали множественное наследование интерфейсов.

это "не совсем" множественное наследование. Кстати, множественного наследования в отдельных применениях очень даже не хватает, приходится дописывать код для имитации.

> И это правильно, я считаю

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

ну тогда еще не так страшно.

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

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

← →
Kerk © (2010-12-31 12:59) [56]

> Игорь Шевченко © (31.12.10 12:47) [55]
> это "не совсем" множественное наследование.

Так и я о том.

> так это ты считаешь, что бездумно, что правильно, и т.д.?

Ну а кто ж еще? Я считаю свою имху, ты свою.

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

А вот это блаблабла и не более. Ибо по таким же соусом можно половину хаскелла в Delphi внедрить.

← →
Kerk © (2010-12-31 13:13) [57]

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

← →
Дмитрий Тимохов (2010-12-31 13:21) [58]

Вообще появление новых путей решения одной и той же прикладной проблемы я считаю бедой для языка. Путей должно быть мало. Лучше один. Чтобы 2 программиста на разных концах планеты для решения прикладной задачи применяли схожие тех. средства.

Согласитесь, что в текущем Дельфи одно и то же можно сделать кучей способов. Один другого запутанней - мы же, программисты, люди творческие, нам за сложность в карман лезть не надо.

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

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

Я несколько, конечно, сгущаю краски. Но мысль, думаю, ясна.

← →
Дмитрий Тимохов (2010-12-31 13:23) [59]

> Kerk © (31.12.10 13:13) [57]
>
> Да и, собственно, судьба КодеГира - инициатора практически
> всех этих очень полезных и прогрессивных изменений - показывает,
> что ерундой они занимались.

Ну в этом ты сильно не прав, я думаю.
Что значит судьба?

КГ - это ОАО. Он продался (погугли, найдешь за сколько), собственники довольны. Чем плохо то?

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

КГ продался. Тоже нормально.

← →
oxffff © (2010-12-31 13:24) [60]

> Kerk © (31.12.10 12:32) [54]
> На самом деле, я считаю, что единственное, чего не хватало
> Delphi - это дженерики. Они действительно очень облегчают
> жизнь. И сделать их надо было лет 10 назад. Ну, может быть,
> с большой натяжкой еще итераторы не помешают. Остальное,
> имхо, хлам.

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

← →
Kerk © (2010-12-31 13:28) [61]

> oxffff © (31.12.10 13:24) [60]

Про анонимные методы я забыл, да.

← →
Дмитрий Тимохов (2010-12-31 16:55) [62]

Да, уж, без анонимных методов свет не мил.

← →
jack128_ (2011-01-01 12:34) [63]

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

← →
Rouse_ © (2011-01-01 20:39) [64]

Как по мне - все что не работает, продаваться не должно, ан нет, увы и ах... Кушайте 2010 и ХЕ...
Декабрь в минус считай за наши же деньги (вива юникод, мать его) и остаток января думаю туда-же...

← →
Alx2 © (2011-01-01 22:35) [65]

>Как по мне - все что не работает, продаваться не должно

Я склонен считать, что нет полностью работающих вещей. Привыкаем к капризному софту и юзаем его так, чтобы не провоцировать :)

← →
Дмитрий Тимохов (2011-01-01 22:58) [66]

>
> Я склонен считать, что нет полностью работающих вещей. Привыкаем
> к капризному софту и юзаем его так, чтобы не провоцировать
> :)

у Розыча все работает!!! )))

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

← →
vuk © (2011-01-03 13:38) [67]

to Kerk © (31.12.10 12:24) [53]:

> А теперь возьмем сабжевое объявление типов внутри объявления
> классов. Оно зачем?

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

type TSomeDialog = class(TBaseDialog) ...... public type TDialogParams = record param1:...; param2:...; end; public class function Execute(var Params: TDialogParams): boolean; end;

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

> vuk © (03.01.11 13:38) [67]

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

← →
Kerk © (2011-01-03 16:01) [69]

Причем отход в одном из его фундаментальных принципов.

← →
vuk © (2011-01-03 16:03) [70]

to Kerk © (03.01.11 15:47) [68]:

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

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

> Хорошо это или плохо - это отход от традиций языка.

От традиций какого конкретно языка?

← →
Игорь Шевченко © (2011-01-03 16:12) [71]

Довольно удобно объявлять встроенным типом Enumerator.
Впрочем, конструкция for .. in тоже отход от того, что было при царе Горохе.
Однако удобно.

← →
Kerk © (2011-01-03 16:35) [72]

> vuk © (03.01.11 16:03) [70]
> > Хорошо это или плохо - это отход от традиций языка.
>
> От традиций какого конкретно языка?

От паскаля, очевидно.
Тут ведь смотри еще какая штука получается. Ну сделаем мы в соответствии с веяниями времени единицей инкапсуляции класс. Ок. А что с модулем будет? Ведь модуль - это не просто текстовый файл, это нечто с секциями interface и implementation (не говоря уже про инициализацию и финализацию). Мне сложно подобрать термин для описания ситуации, но надеюсь, "пересечение компетенция" подойдет. Т.е. получается ситуация, о которой выше писал Дима Тимохов - мы одно и то же можем делать кучей способов. В сях, например, такого противоречия нет, там такие классы органично смотрятся.

← →
vuk © (2011-01-03 16:52) [73]

to Kerk © (03.01.11 16:35) [72]:

> А что с модулем будет?

А ничего не будет. Он тоже контейнер типов и данных, но более высокого уровня. Не?
К тому же модуль, как конечная единица инкапсуляции катит только при процедурном подходе. При ООП - уже нет.

← →
tesseract © (2011-01-05 12:08) [74]

> Впрочем, конструкция for .. in тоже отход от того, что было
> при царе Горохе.

Избавляет от with .. do и лишних переменных. Но иногда так читать тяжело.

← →
_Юрий (2011-01-05 12:32) [75]

> Rouse_ © (01.01.11 20:39) [64]

> Как по мне - все что не работает, продаваться не должно,
> ан нет, увы и ах... Кушайте 2010 и ХЕ...
> Декабрь в минус считай за наши же деньги (вива юникод, мать
> его) и остаток января думаю туда-же...

Чото я глубины мысли не понял. Юникод вроде как работает. Что не должно продаваться?

> Kerk ©
>Хорошо это или плохо - это отход от традиций языка.

Слепое следование традициям только потому, что это традиции - одна из наиболее тупых вещей, свойственных человеку.
Развивать мысль я не буду - она или понятна, или объяснение бесполезно.

← →
Kerk © (2011-01-05 12:47) [76]

> _Юрий (05.01.11 12:32) [75]
> Слепое следование традициям только потому, что это традиции
> - одна из наиболее тупых вещей, свойственных человеку.
> Развивать мысль я не буду - она или понятна, или объяснение
> бесполезно.

Спасибо, что уделил мне время, о великий гуру.

← →
_Юрий (2011-01-05 12:48) [77]

> Kerk © (05.01.11 12:47) [76]

> Спасибо, что уделил мне время, о великий гуру.

Аминь. Покойся с миром.

← →
имя (2011-01-05 12:49) [78]

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

← →
Дмитрий Тимохов (2011-01-05 15:57) [79]

Я ушел от for in в сторону обычного for.
Не вижу большого смысла в них.

← →
Kerk © (2011-01-05 16:03) [80]

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

← →
Kerk © (2011-01-05 16:05) [81]

> Дмитрий Тимохов (05.01.11 15:57) [79]
>
> Я ушел от for in в сторону обычного for.
> Не вижу большого смысла в них.

Синтаксический сахар, не более.

← →
DiamondShark © (2011-01-05 17:50) [82]

> Дмитрий Тимохов (05.01.11 15:57) [79]
> Я ушел от for in в сторону обычного for. Не вижу большого
> смысла в них.

LINQ, например.
Результат запроса -- инумератор анонимного типа, у которого ни индексера ни свойства Count.

Вообще-то, коллекция последовательного доступа -- такая же фундаментальная структура, как и индесная коллекция.

← →
Kerk © (2011-01-05 18:11) [83]

> DiamondShark © (05.01.11 17:50) [82]
>
> > Дмитрий Тимохов (05.01.11 15:57) [79]
> > Я ушел от for in в сторону обычного for. Не вижу большого
> > смысла в них.
>
> LINQ, например.
> Результат запроса -- инумератор анонимного типа, у которого
> ни индексера ни свойства Count.

В Delphi ничего подобного нет. Если я не прозевал, конечно.

← →
DiamondShark © (2011-01-05 18:15) [84]

> В Delphi ничего подобного нет.

Да? Даже в дотнетовской инкарнации?
Пичаль...

← →
Игорь Шевченко © (2011-01-05 18:19) [85]

> В Delphi ничего подобного нет. Если я не прозевал, конечно.

for..in - это как раз оно и есть: "инумератор анонимного типа, у которого ни индексера ни свойства Count"

http://17slon.com/blogs/gabr/2007/03/fun-with-enumerators.html

← →
Kerk © (2011-01-05 18:22) [86]

Не, я про LINQ

← →
DiamondShark © (2011-01-05 18:23) [87]

> Kerk © (05.01.11 18:11) [83]
> DiamondShark © (05.01.11 18:15) [84]

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

LINQ просто как пример.

Сказать по правде, идея enumerator`ов в том виде, как она реализована в .net мне не нравится. В первую очередь тем, что сам enumerator там изменяемый. Зря они в Дельфи сделали так же.

> сам enumerator там изменяемый

Какэто?

> DiamondShark © (05.01.11 19:32) [89]
> > сам enumerator там изменяемый
> Какэто?

Он является stateful объектом. MoveNext изменяет его состояние.

> DiamondShark © (05.01.11 20:36) [91]
> Очень интересно было бы взлянуть на инумератор без состояния.

Ленивый односвязный список.

Кстати, вспомнил тут, что у того же Буча рассматриваются активные и пассивные итераторы. То, что обычно подразумевается под итератором(инумератором) - это активный итератор. Пассивный - это вообще не объект, а метод, которому передается ссылка на функцию, которую он применяет к каждому элементу набора.
Вот, помнится, еще у коллекций в TurboVision бали методы-итераторы - ForEach, FirstThat, LastThat. Как раз пассивные итераторы.

← →
Дмитрий Тимохов (2011-01-05 22:10) [94]

я все равно стою на том, что чем меньше примитивов, тем лучше )))

в этом смысле классический паскаль был для меня достаточным для решения прикладных задач.

вообще, сила любого языка, я думаю, не в языке как таковом, а в библиотеках.

to Дмитрий Тимохов (05.01.11 22:10) [94]:

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

Вот скажи мне, ты лично дофига прикладных задач решил на классическом паскале? Я вот - ни одной.

> Дмитрий Тимохов (05.01.11 22:10) [94]
> вообще, сила любого языка, я думаю, не в языке как таковом,
> а в библиотеках.

Не соглашусь. Сам язык очень важен. Иначе бы мы до сих пор писали на Фортране :)

_Юрий (05.01.11 12:32) [75]
> Слепое следование традициям только потому, что это традиции - одна из
> наиболее тупых вещей, свойственных человеку.

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

Развивать мысль я не буду - она или понятна, или объяснение бесполезно.
© _Юрий

> vuk © (05.01.11 22:16) [95]
> Вот скажи мне, ты лично дофига прикладных задач решил на
> классическом паскале? Я вот - ни одной.

Я - наверное, парочку, вряд ли больше (на TP, конечно, до фига, но это уже не классический, так что не считается). Но это же не значит, что классический Паскаль недостаточен?

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

> я все равно стою на том, что чем меньше примитивов, тем
> лучше )))
>
> в этом смысле классический паскаль был для меня достаточным
> для решения прикладных задач

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

← →
Дмитрий Тимохов (2011-01-05 22:38) [100]

>
> Вот скажи мне, ты лично дофига прикладных задач решил на
> классическом паскале? Я вот - ни одной.

Леш, ты же знаешь - я не использую DFM и все с этим связанное.
Т.е. в этом смысле RAD как таковой я не пользуюсь.

Классы, конечно, использую, куда без них. Но все это и на паскале можно делать. Эвона, в WinAPI нет классов, а жить можно.

Я утрирую, конечно, но либы штука важная.

> Alkid © (05.01.11 22:20) [96]

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

Юра Зотов когда-то приводил пример про сложность либы по каким тот там ынтыгралам в частичных проиходных (деталей не помню). что-то типа, что такую либу писать человекогода.

> Игорь Шевченко © (05.01.11 22:37) [99]

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

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

to Юрий Зотов © (05.01.11 22:28) [98]:

> Но это же не значит, что классический Паскаль недостаточен?

Достаточен. Вопрос только в том, для чего достаточен.

В какой-то мере и брэйнфак, например, достаточен. Но это же не повод? :)

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

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

to Дмитрий Тимохов (05.01.11 22:38) [100]:

> Леш, ты же знаешь - я не использую DFM и все с этим связанное.

Ну а я использую. Но тут уж каждый сам себе буратино. :)

> Классы, конечно, использую, куда без них. Но все это и на
> паскале можно делать. Эвона, в WinAPI нет классов, а жить
> можно.

На классическом паскале - низзя. Кстати. Ты много пробовал писать оконные приложения на чистом WinAPI? У меня, вот, в какой-то момент (где-то еще на уровне BP for Windows) желание такое пропало начисто. Даже OWL, которая была совсем не RAD-библиотекой дело упрощала на порядок.

> Дмитрий Тимохов (05.01.11 22:38) [100]
> на нем и пишут до сих пор очень-очень много.
> просто фортран использовался для расчетов.
> как раз он там либы - штука архи важная.
>
> Юра Зотов когда-то приводил пример про сложность либы по
> каким тот там ынтыгралам в частичных проиходных (деталей
> не помню). что-то типа, что такую либу писать человекогода.

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

Тем не менее, мы пишем не на Фортране и это уже доказывает, что не все решается библиотеками. Сам язык и те абстракции, которые он дает, важны.

← →
Дмитрий Тимохов (2011-01-05 23:57) [105]

>
> Тем не менее, мы пишем не на Фортране и это уже доказывает,
> что не все решается библиотеками. Сам язык и те абстракции,
> которые он дает, важны.

наука пишет на фортране )))

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

---

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

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

но в определенный момент у тебя есть капитошка с определенным количеством воды (мозга) в нем.

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

как-то так ))

я, кстати, ничуть не консерватор. все пробую из нововведений.
просто мне проще быть проще (с) сам придумал

если не ошибаюсь, Игорь Шевченко про овощ в нужном месте в нужное время говорит. возможно я тоже научусь применять правильные овощи в правильное время.

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

было время, я увлекался функциональным программированием. именно в Хаскелле я понял, что такое быстрая сортировка ))) и насколько это просто.

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

> Игорь Шевченко © (05.01.11 22:37) [99]
>
> а вот люди провели исследование и выяснили, что на определенное
> количество строк кода в среднем приходится определенное
> количество ошибок. Вне зависимости от языка. Отсюда вывод
> - чем меньшим количеством строк кода может быть решена конкретная
> задача, тем меньше ошибок будет при ее решении.

Молодцы люди. Я тоже всем говорю, что на перле нужно только так и писать: "(1 x $_) !~ /^(11+)\1+$/ && print while ++ $_", ошибок меньше будет.

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

to Дмитрий Тимохов (05.01.11 23:57) [105]:

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

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

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

"потому что во многой мудрости много печали; и кто умножает познания, умножает скорбь" (Еккл. 1, 18)

мозг вообще надо оберегать, тем более от неочевидных моментов языков программирования.

← →
имя (2011-01-06 01:03) [110]

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

> Дмитрий Тимохов (05.01.11 23:57) [105]
>
> и вот, если ты будешь тратить часть своего мозка (памяти)
> на то, чтобы помнить неочевидные моменты твоего языка программирования,
> то у тебя останется меньше жидкости на другие стороны твоей
> профессиональной деятельности.

"Неочевидные моменты языка программирования" - это, скорее, про С++ и про такие кунштюки в Дельфи, как этот с областями видимости. Это называется "accidental complexity". В этом смысле C#проще Дельфи, поскольку там правила областей видимости более регулярны.

Кстати, вопрос с достаточностью языка - это тоже вопрос не очень очевидный. В смысле тьюринг-полноты достаточен и ассемблер :) Тот продукт, который мы недавно выпустили на C#, раньше писался на С++. То есть С++ был *достаточен*, но C# оказался лучше.

← →
_Юрий (2011-01-06 11:30) [112]

> Юрий Зотов © (05.01.11 22:20) [97]
>
>

Абсолютно верно.
Ключевое слово - "слепое".
Но таких вот "безголовых новаторов" не особо много, я лично ни одного не знаю, а "безголовых консерваторов" дофига

> _Юрий (06.01.11 11:30) [112]
> Но таких вот "безголовых новаторов" не особо много, я лично
> ни одного не знаю, а "безголовых консерваторов" дофига

Исходя из закона больших чисел, их количество примерно одинаково. И если Вам встречаются только одни "консерваторы", то это означает, что либо Вам просто не везет (что менее вероятно), либо Вы даете людям ошибочные оценки (что более вероятно).

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

А если это так, то кто же тогда "безголовый новатор"?
:o)

> _Юрий (06.01.11 11:30) [112]
> Но таких вот "безголовых новаторов" не особо много, я лично
> ни одного не знаю, а "безголовых консерваторов" дофига

Мой опыт говорит ровно об обратном ;)

> Alkid © (06.01.11 13:10) [114]

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

Назвать эту взвешенную осторожность "безголовостью" небезголовому человеку довольно сложно. Обычно ее называют опытом, а иногда даже и мудростью.
:o)

> Юрий Зотов © (06.01.11 13:34) [115]
> Поскольку консерваторами становятся не просто так, а после
> набития немалого числа шишек (которые новаторы еще набить
> не успели, иначе они стали бы консерваторами) - что приводит
> к взвешенной осторожности в решениях.

Это тоже не всегда так. Бывают и люди, которые в принципе боятся нововведений и предпочитают старые, проверенные способы даже тогда, когда они уже не адекватны ситуации.

Простых ответов нет. Надо быть мудрее и искать гармонию :)

> Alkid © (06.01.11 13:45) [116]
> Простых ответов нет. Надо быть мудрее и искать гармонию :)

Совершенно верно. Стараясь при этом воздерживаться от крайних точек зрения и радикальных оценок.
:o)

Удалено модератором
Примечание: Не на базаре

> DiamondShark © (06.01.11 14:47) [118]

Ты хоть сам понял, чего выдал? Цитирую:

> то вторым прямая дорога в биореактор.

Это я так понял ты про "старых перечниц", верно? Хорошо. Далее:

> так и будет горлодранской шантропой (пока не повзрослеет,
> конечно)

Т.е., надо понимать, что как повзрослеет, туды же, в биореактор? Ибо, тоже превратится в "старых перечниц"? Так?

Получается или ты "горлодранская шантропа" или в биореактор?
Т.е. "горлодранская шантропа" - наше все?

> Получается или ты "горлодранская шантропа" или в биореактор?

Ну вот смотри: ты утром просыпаешься, а вечером засыпаешь.
Получается или ты просыпаешься, или ты засыпаешь.
Т.е. ты всё время спишь.

Полуоффтоп про языки: http://www.americanscientist.org/issues/id.3489,y.0,no.,content.true,page.1,css.print/issue.aspx

> DiamondShark © (06.01.11 17:15) [120]

> Т.е. ты всё время спишь.

Неа. Я все время бодрствую... :)

Ну, так у тебя в том посте так и получилось. Про промежуточные состояния ты там не упомянул. Так что, уж как получилось...

> asail © (07.01.11 07:03) [122]
> Про промежуточные состояния ты там не упомянул.

Т.е. если о чём-то не упомянуто, то, по-твоему, это равнозначно утверждению об отсутствии?

← →
Дмитрий Тимохов (2011-01-07 18:11) [124]

Хватит чушь нести, никто уже не понимает о чем вы.

Наткнулся на интересное поведение в D2010 Найти похожие ветки