18-ть лет с Delphi

четверг, 5 сентября 2013 г.

Про "словари" в Delphi

Навеяно вот этим - http://18delphi.blogspot.ru/2013/09/blog-post_3.html?showComment=1378309406219#c8331945982295222932

Друзья мои!

Давайте всё же пытаться "отделять мух от котлет".

Есть использование "словарей" как СТРУКТУРЫ данных - ключ-значение. А есть - использование "словарей" для передачи "нефиксированного списка "именнованных параметров"".

Это - РАЗНЫЕ вещи.

Это надо - ПОНИМАТЬ.

То, что "именованные параметры" сделаны в Python ЧЕРЕЗ "словари" - я (теперь) - ЗНАЮ.

Не надо мне об этом напоминать.

Но это всего лишь - "совпадение".

Теперь о "словарях" как о СТРУКТУРЕ данных.

Есть такое мнение - http://18delphi.blogspot.ru/2013/09/blog-post_3.html?showComment=1378316009315#c1276656632326196246
"Начиная с версии 2009 (если не ошибаюсь) в Delphi появились обобщённые типы (generics).
Так что, можно сказать, словари есть."

На мой взгляд - generic'и и "словари" - СЛАБО связанные вещи. То есть конечно generic'и это КОНЕЧНО - "удобная почва для реализации словарей". Не спорю.

Как и другие шаблонные решения.

Но - НЕ БОЛЕЕ ТОГО.

Вывод "есть generic'и - значит считай есть словари - В КОРНЕ - неверен".

Generic'и - достаточное, но не НЕОБХОДИМОЕ условие для ВОЗМОЖНОСТИ существования словарей.

Я словарей сделал - "много разных". ЗАДОЛГО ДО появления generic'ов.

(да и вообще ДО Delphi)

Как? Да ПО-РАЗНОМУ, начиная от использования дискриминантов и вариантных типов и кончая "примесями".

Если есть КОНКРЕТНЫЕ вопросы - задавайте, я - ОБЯЗАТЕЛЬНО отвечу.

Сходная тема тут - http://18delphi.blogspot.com/2013/07/2.html (ну и далее - по ссылкам).

Теперь про "переменные списки именованных параметров". Которые НАПРЯМУЮ не являются "словарями". Хотя и МОГУТ быть ими реализованы. И БОЛЕЕ ТОГО - РЕАЛИЗОВАНЫ в Python.

Я в Delphi делаю примерно так (просто как пять копеек):

type

TNamedParam = record

rName : String;

rValue : String;

end;

function Param(aName : String; aValue : String) : TNamedParam;

begin

Result.rName := aName;

Result.rValue := aValue;

end;

procedure SomeFuctionWithNamedParams(aParams : array of TNamedParam);

begin

for l_Index := Loaw(aParams) to High(aParams) do

ProcessSomeParam(aParams[l_Index]);

end;

SomeFuctionWithNamedParams([

Param('Size', '10'),

Param('Height', '100'),

Param('Width', '200')

]);

всё! НИКАКОЙ МАГИИ.

Не забываем про дискриминанты и overload.

(Про Automation и IDispatch - я СОЗНАТЕЛЬНО умолчал).

http://18delphi.blogspot.ru/2013/09/blog-post_3.html?showComment=1378304020959#c7539045129727196205

Понятно, как я бы переделал бы SetFontProps?

И вообще - я сторонник СТРОГОЙ ТИПИЗАЦИИ.

А не "разбора строк", как это зачастую делается у Embarcadero в FM (интересно кстати?).

И не сторонник "превращать Delphi в Python". Равно как и не сторонник обратного.

------

Я - ЛЮБЛЮ duck-typing и МНОЖЕСТВЕННОЕ наследование, но считаю, что области их применения должны быть СИЛЬНО ограничены.

Равно как и области применения "перегрузки операторов".

Ну это я так - "на будущее"...

среда, 4 сентября 2013 г.

Про ARC

Мне НЕ НРАВИТСЯ, что Embarcadero пытается "насильно запихать всех" в русло ARC (Automatic Reference Counting).

Я бы ЛИЧНО предпочёл бы, чтобы мне ЛИЧНО оставили бы ВОЗМОЖНОСТЬ "ручного управления ссылками" (как это сделано кстати у Apple - хочешь retain/release, а хочешь - ARC).

Я ПРИВЫК - "считать копейки" и "держать руку на пульсе".

Я НЕ ЛЮБЛЮ Garbage Clollector (особенно в исполнении Java).

И я с ПРЕДУБЕЖДЕНИЕМ отношусь к использованию ARC "в вену". Я бы предпочёл, чтобы мне оставили бы ВЫБОР. И на мобильных устройствах - тоже.

Это МОЁ ЛИЧНОЕ мнение.

P.S. зато мне нравится движение в сторону Immutable Strings.

P.P.S. А ещё бы я бы предпочёл иметь ВОЗМОЖНОСТЬ работать с объектами на стеке и Smart Pointer'ами в стиле C++.

Offtopic. ПРОСЬБА ко всем читателям и КОММЕНТАТОРАМ блога

Друзья мои!

Мы все - ВЗРОСЛЫЕ люди. Сложившиеся.

Со своими привычками и принципами.

Посему - хочу ПОПРОСИТЬ - давайте снизим "накал страстей".

Не надо "пытаться воспитывать" друг друга. А также - "менторствовать".

Также не надо пытаться задавать "риторические вопросы".

Давайте обсуждать ТЕХНИЧЕСКИЕ и технологические темы.

И давайте не будем проецировать критику на личностное отношение.

Давайте будем - КОРРЕКТНЫ.

И не надо пытаться "евангелировать". Про Python и Haskell - я давно ВСЁ понял. Они - ЛУЧШИЕ языки :-)

Упоминания других языков (кроме Delphi), а также ссылки на литературу - ПРИВЕТСВУЮТСЯ.

Но не надо повторять одно и то же "слабое сообщество Delphi", "архаичная IDE", и прочее. Не НАДО.

Я лично - ВСЁ УЖЕ - понял. Я - не дурак :-)

И МНОГОЕ - впитал и "намотал" на ус". И за многое - СПАСИБО!

То, что я завтра "брошусь программировать на Python или Haskell" - не ждите. Я и так - примерно на ПЯТИ разных языках программирую. КАЖДЫЙ день.

В общем - ДАВАЙТЕ УВАЖАТЬ друг-друга и принципы друг-друга.

Про БД и SQL я кстати УЖЕ тоже писал (http://18delphi.blogspot.com/2013/03/sql.html). Я - НЕ ИСПОЛЬЗУЮ их. И НЕ ПЛАНИРУЮ использовать.

МНЕ ИНТЕРЕСНЫ - UML, TDD, DUnit, DSL, "шаблоны", управление требованиями, общение с "заказчиками", Delphi, примеси, АОП.

Давайте постараемся остаться в этих рамках.

Ссылки на ДРУГИЕ методики, фреймворки и языки - ПРИВЕТСВУЮТСЯ.

Но не надо "евангелировать".

Сказали - раз. Сказали - два. Дали - ссылку на документацию. СПАСИБО! Но! Знайте меру.

Комментарии в блоге - ПРИНЦИПИАЛЬНО не удаляю. Если они не содержат ненормативную лексику или прямые личные оскорбления.

P.S. И я кстати не СЧИТАЮ, что стиль комментариев Всеволода Леонова - "идеален". Отнюдь - нет. Хотя я его ОЧЕНЬ уважаю.

P.P.S. Для "Sun of gun" - не надо пытаться "флеймить". В стиле "сообщество слабое". СЛАБОЕ! Ну и что? Вы своим комментарием что-то НОВОЕ привнесли?

P.P.P.S. Простите (!), что я своим этим постом попытался "повоспитывать" ВЗРОСЛЫХ людей. ПОСТАРАЮСЬ этого больше не делать.

P.P.P.P.S. Если МЫ ВСЕ постараемся перестать "воспитывать" друг друга, а начнём сосредотачиваться на "техническом" предмете дискуссии - мы добьёмся ГОРАЗДО БОЛЬШЕГО.

О fluent interface'ах

Придумка Фаулера (http://18delphi.blogspot.com/2013/09/blog-post_4.html) - конечно - ХОРОША.

Но не в переложении русскоязычного автора - http://18delphi.blogspot.com/2013/09/blog-post_3.html.

Русскоязычный автор "потерял" в своей статье использование new. И из-за этого - "смазал" всю идею Фаулера.

Я САМ таким - ДАВНО пользуюсь. Ещё задолго до Фаулера.

Меня тут спросили - "как я этим пользуюсь".

Да примерно также как и Фаулер.

Примерно в таком ключе:

TTreeBuilder.Make(Tree)
.AddNode('Text1')
.AddNode('Text2')
.AddNode('Text3', TSpecialNodeType1)
.AddNode('Text4', TSpecialNodeType2)
.OpenLevel
.AddNode('Sibling 1')
.AddNode('Sibling 2')
.AddNode('Sibling 3')
.OpenLevel
.AddNode('SubSibling 1')
.CloseLevel
.CloseLevel
.AddNode('Text 5');

- я сам это придумал. Задолго до Фаулера.

И не считаю это "революционным". Я считаю это "эволюцией" цепочечных выражений вида:
DoParams(TParamsList.Create.AddParam("Param1").AddParam(123).AddParam(TClass.Create).AddParam("ParamX"))

Более того, я считаю и это эволюцией идеи Кернигана и Ричи. В виде:
cout << "Hello, man" << "you're number" << 16 << "in the list of less than " << 100.5 << endln;

О чём и написал Всеволод Леонов - http://18delphi.blogspot.com/2013/09/blog-post_3.html?showComment=1378273720721#c6925185551184111953

Хотя некоторые оппоненты и считают, что "пример Леонова не к месту".

Я считаю, что пример Леонова - УМЕСТЕН и грамматически и семантически правильный.

Что до того, что "сам придумал" - не спрашивайте меня proof-link'и. Их - НЕТУ. Придётся "поверить на слово". А я обычно - слово держу.

Я по молодости - статей не писал. А - зря. Сейчас - восполняю этот пробел.

Я САМ много чего "придумал" и SAX, и XML, и XPath и Publisher/Subscriber.

И IUnknown и "подсчёт ссылок".

Это конечно - выглядит "голословным", но это - так.

У меня есть коллеги, которые могут подтвердить. Если захотят. Ну а если не захотят.. То - не подтвердят. Имеют право...

Что до fluent interface'ов, то как ПРАВИЛЬНО заметили - они УДОБНО и БЕЗОПАСНО реализуются - ТОЛЬКО через ИНТЕРФЕЙСЫ (ключевое слово - interface).

Я же - привык - "считать копейки".

Я ОБЫЧНО - пишу код, а потом открываю отладчик и смотрю на его ассемблерный аналог.

В наш век "гигабайтов и гигагерц" это наверное выглядит - "причудой". Ну что же. Считайте меня - старомодным занудой.

Есть ОДИН БОЛЬШОЙ минус в fluent interface'ах. КАЖДЫЙ возврат интерфейса из функции ведёт к однократному, а то и двукратному вызову AddRef/Release.

А они - недёшевы. С учётом требований "атомарности".

Посему - я сам - стараюсь отходить от fluent interface'ов.

(Ну и не только поэтому).

Я сам сторонник "классического" подхода. "Данные и алгоритмы". Вирт.

Отдельно ДЕКЛАРАТИВНО описываем структуру, а отдельно ИМПЕРАТИВНО - алгоритм генерации экземпляров объектов по этой структуре.

И я продолжаю склоняться к этой парадигме.

А так - идея Фаулера - хороша. Только ничего "молодого" и "революционного" я в ней не вижу.

Но это - НЕ ВАЖНО.

Друг пишет. О моделях и программировании

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

Я МЕЧТАЮ - именно об этом!!!

Оригинал шедевра

http://martinfowler.com/bliki/FluentInterface.html

Только Фаулер - СИЛЬНО УБЕДИТЕЛЬНЕЕ за счёт использования new. А в "шедевре" (http://18delphi.blogspot.com/2013/09/blog-post_3.html) - его нет.

вторник, 3 сентября 2013 г.

Странная книга. Марри Кантор. "Управление программными проектами"

ПОРАЖАЕТ количеством ПОБЕДНЫХ реляций про RUP и UML.

Хотя отсутствие ПУБЛИЧНЫХ success story и настроение "в интернетах" - говорит об обратном.

Странно всё это....

http://www.slideshare.net/booksinslides/ss-5043474
http://www.ozon.ru/context/detail/id/1136908/

Книга - полезная... Но её настроение про "промышленный стандарт" и "множество вариантов использования" - настораживает...

Я эту книгу читал и раньше. Пару раз. Но в свете критики "UML - никому не нужен" - переосмысливаю, всё по-другому.

Приведу цитату из книги:

"НАИЛУЧШИЙ ВЫБОР
Лучше всего, если для разработки архитектуры программного обеспечения ваша организация выберет стандарт UML. Если разработка не будет создана на основе этого стандарта и не будет объектно-ориентированной, она никогда не сможет стать КОНКУРЕНТНОСПОСОБНОЙ".

На основании ЧЕГО автор так БЕЗАПЕЛЯЦИОННО это заявляет? Где success story? Почему он считает, что вправе "напялить шляпу гуру"? Где мотивация? Какие задачи решаем?

Нас с Максом и с Леоновым за гораздо более осторожные высказывания - "побили ногами" (http://habrahabr.ru/post/188604/). И были в общем-то - правы.

ГДЕ UML в Windows NT или "ядре Linux"?

Дальше - БОЛЬШЕ:

"Иногда покупатели и инвесторы настаивают на том, чтобы при создании архитектуры продукта разработчики руководствовались другими базовыми средствами. Если на этом настаивает покупатель, то с ним придётся согласится. Но даже в этом случае следует как можно больше пользоваться стандартом UML. Эта задача часто облегчается тем фактом, что многие другие подходы к созданию архитектуры имtют много общего со стандартом UML."

ОТКУДА это следует? Где мотивация? Какие задачи решаем? Где success story?

"Лозунги". Не более того. :-(

Дальше - БОЛЬШЕ:
"В любом случае избегайте использования идиосинкразитесчких схем. Если коллектив чересчур увлёкся ими, вы как руководитель должны быть встревожены и предпринять немедленные действия во избежание таких "отклонений". Примером таких действий может быть организация доступа к стандарту UML, обучение персонала или обсуждение необходимости и выгод соблюдения стандартов."

Блеск!!!

"Учение Маркса - ВСЕСИЛЬНО, потому, что оно - ВЕРНО".

Хочется автору задать ОДИН ПРОСТОЙ вопрос - "а уж не про UML ли этот абзац написан?"

Вообще говоря - МЕЧТАЮ - написать книгу про "мой UML".. Но не ТАКУЮ. А с ПРАВИЛЬНОЙ МОТИВАЦИЕЙ.

Как говорил проф. Преображенский - "БРОНЯ, а не бумажка!"

Которую я "для себя" - НАШЁЛ. А вот для "массы" - похоже, что - что пока - нет.

МОТИВАЦИЯ. Это - главное. КАКУЮ ЗАДАЧУ РЕШАЕМ. От этого надо отталкиваться.

К книге Лармана (хотя она и ХОРОША) - у меня - примерно такие же вопросы (почему кстати "водопад" ХУЖЕ "итеративной модели" - так никто "на пальцах" - никто толком и не рассказал).

Про Фаулера - так я вообще - молчу.. Рассказал про "нотацию". И что? МОЛОДЕЦ! Но! "Какие вопросы и КАК решаем"?

Раньше я подобные "рекламные лозунги" - как-то пролистывал по-диагонали... А теперь - почему-то начал обращать внимание...

Наверное потому, что САМ ищу "мотивацию"...

Найду "мотивацию" - продолжу посты про UML.

Ну и в плане "лозунгов" -
http://msdn.microsoft.com/ru-ru/library/dd409465.aspx
http://ht.on.ufanet.ru/article.htm
http://ooad.asf.ru/standarts/UML/UMLSimple/

"Киты" нам голову морочат? Где "мотивация"?