Есть ли будущее у DELPHI?

Цитата Flex Ferrum @ 21.02.13, 12:51

Что хоть отписал то? А то там пока модерацию пройдёт...

Цитата --Ins-- @ 21.02.13, 20:52

Ага. Скорее всего нас обоих вскоре забанят За "недружественность"

Ну вот видите - чел вроде и наезжат на "сокрытие", а сам по жизни юзает сеттеры\геттеры "с громадным числом проверок" и заботится о "согласованности состояния"

Цитата MyNameIsIgor @ 22.02.13, 08:46

"динамическое/статическое субтипирование"?

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

Цитата korvin @ 22.02.13, 09:11

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

Ну, вот, теперь мне понятно наше разночтение. Я понимал статическое субтипирование как создание подтипа в коде, а динамическое - как создание подтипа во время исполнения, т.е. метапрограммирование...

Цитата --Ins-- @ 22.02.13, 08:53

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

Последователь великого-двуликого Жирика? В анфас - клоун разговорного жанра, а в профиль - рассудительный и умудренный сединами профессор?

Цитата leo @ 22.02.13, 09:18

Последователь великого-двуликого Жирика? В анфас - клоун разговорного жанра, а в профиль - рассудительный и умудренный сединами профессор?

Не исключено Но посмотреть все равно будет любопытно

Цитата MyNameIsIgor @ 22.02.13, 09:15

Ну, вот, теперь мне понятно наше разночтение. Я понимал статическое субтипирование как создание подтипа в коде, а динамическое - как создание подтипа во время исполнения, т.е. метапрограммирование...

Ну вот, а не говорю я именно про диспатчинг(методов), потому что это в общем случае может относится не только к «интерфейсу объекта», но и к полям записей например.

DevExpress никогда не будет поддерживать FireMonkey
http://donaldshimoda.blogspot.com/2012/09/...firemonkey.html

Добавлено 04.03.13, 19:54
И еще одно улучшение: теперь бывшую библиотеку AnyDAC (теперь FireDAC) - нельзя компилировать с помощью FreePascal/Lazarus!
http://donaldshimoda.blogspot.com/2013/03/...upport-for.html

Что тут можно сказать? Можно закапывать.

Цитата Бобёр @ 04.03.13, 20:08

Что тут можно сказать? Можно закапывать.

Та они сами закапываются. =)

В общем, Бобер разрешил и одобрил. Лет 10 назад ещё одобрил, и вот...

Цитата Бобёр @ 05.03.13, 19:35

Лет 10 назад ещё одобрил, и вот...

10 лет назад еще не было раздела холиваров

"Есть ли будущее у Delphi, нету ли будущего у Delphi - науке это неизвестно". Но диалог с Всеволодом в той статье, ссылку на которую дал Смайк вышел весьма показательный. Читать можно начинать где-то с комментария №39.

Это сообщение было перенесено сюда или объединено из темы "Для каких задач Delphi лучше других технологий?"

Цитата Flex Ferrum @ 06.03.13, 20:28

"Есть ли будущее у Delphi, нету ли будущего у Delphi - науке это неизвестно". Но диалог с Всеволодом в той статье, ссылку на которую дал Смайк вышел весьма показательный. Читать можно начинать где-то с комментария №39.

Надо тему переименовать, мы тут не о Delphi А диалог да - зачетный.

Это сообщение было перенесено сюда или объединено из темы "Для каких задач Delphi лучше других технологий?"

Даже в разделе Delphi: Общие вопросы. полное затишье. На первой странице темы еще за февраль!

Диалог закончился следующим образом:

Цитата

78. Vsevolod Leonov Says:
March 6th, 2013 at 8:13 am@Flex Ferrum
>>И запрошу за это N килодолларов (так сказать, любой каприз - за ваши деньги! Его ведь оттестировать надо, отдокументировать и т. п.!). Использование этого монстра приведёт к просадке производительности на пару порядков, и вам придётся докупить ещё пару 8Gb-плашек к сервку, на котором эта модель будет обсчитываться. Зато "Коробка" получится мегауниверсальной. Буквально, на все случаи жизни. Вас это устроит?
Это уже не какое-то управление проектами. Это уже высший пилотаж "сейлза". Да Вам цены нет!
На самом деле, есть правило 20/80, когда 20 процентов функционала нужны 80 процентов пользователей.

>>А как вы работу у меня принимать будете?
Ну как… как обычно. Посмотрю в ТЗ, посмотрю в Ваши (наши) честные глаза… вздохну слезой… А Вы мне дадите 101 обоснование подписания доп. соглашения к ТЗ на еще 30% стоимости проекта. Но за это я потребую от Вас пламенной речи о качестве кода в фундаменте системы.

>>А ограничения на эти самые входные значения - они откуда возьмутся?
Да мне просто не нравится сам факт того, что вводить домены нельзя. Нельзя это сделать дискриптивно (может, я не знаю… отстал, бедный). Ладно, еще инициализацию можно совместить с конструктором… Но не надо унывать - я раз в месяц вижу свежие коды, где в классе TPerson есть свойство age типа integer. И ничего, с ума еще не сошел.

>>И как вы будете контролировать выход за эти ограничения на этапе активной разработки и отладки?
Плохо буду контролировать. Видите, мы уже договорились до разбиения на этапы. Мне вообще Вы начали очень импонировать.
Поделили "пользователей класса", ввели понятия "этапы разработки". Никакого сарказма. Если найдете, где про это прочитать - сообщите. Буду рекомендовать другим.

>>до детально прописанных сценариев использования.
А это "контракт" или нет?

>>Из предложенной вами задачи оптимизации логистики заготовок по цеху?
Не знаю. Пишем предметно-ориентированный фреймворк. Вопрос дня - можно ли задавать/иметь свойство объем? (я со своей стороны хочу ООП прищучить).

>> Так что вы мне сказать то хотели?
Да выбиваю из Вас (или "вас" в широком смысле) определить роль "контракта" в контексте этапов проектирования/программирования классов. Если Вы ("вы" в широким смысле) - апологеты "контрактов", а я тут типа "адвокат дьявола", ну и вотрите мне. Только увольте читать 100 раз, что ООП без контракта - ничто, а контракт = интерфейс = целостность.

>>Что нет заказчиков, которые могут внятно свои хотелки сформулировать?
Готов закрыть тему за Вашим явным преимуществом. Как только Вы разделил "заказчиков" на группы мне ("мне" в широком смысле) стало всё ясно.
Или "предметно-подготовленные пользователи" вам мамой клянутся, что никогда-никогда не будут вызывать методы ваших классов с некорректными аргументами?

79. Vsevolod Leonov Says:
March 6th, 2013 at 8:23 am…
>>Или "предметно-подготовленные пользователи" вам мамой клянутся, что никогда-никогда не будут вызывать методы ваших классов с некорректными аргументами?
Не! мы будем писать "контракты"

80. Flex Ferrum Says:
March 6th, 2013 at 1:15 pm>> Это уже не какое-то управление проектами. Это уже высший пилотаж "сейлза". Да Вам цены нет!
Правда, те заказчики, с которыми мне приходилось сталкиваться, очень хорошо умели считать деньги, а потому подобные штуки с ними не проходили… Но это мои заказчики. У вас могло быть несколько иначе.

>> На самом деле, есть правило 20/80, когда 20 процентов функционала нужны 80 процентов пользователей.
В данном случае этот закон Парето имеет ограниченное применение. Если что-то можно не делать - то это лучше не делать.

>> Ну как… как обычно. Посмотрю в ТЗ, посмотрю в Ваши (наши) честные глаза…
Стоп-стоп-стоп… А ТЗ у нас откуда взялось? Вы же мне буквально перед этим говорили, что требовать с заказчика хотелки - это невыполнимая задача. Из чего тогда ТЗ то состоит? И (в продолжение) может быть, если не растекаться мыслью по коду и закладывать функционал на будущее, то и доп. соглашения подписывать не надо?

>> Да мне просто не нравится сам факт того, что вводить домены нельзя. Нельзя это сделать дискриптивно (может, я не знаю… отстал, бедный).
Домены от вас никуда не уйдут. Надо только правильно понять - какие домены действительно потребны, а не брать их с фонаря. Да и как домены связаны с assert’ами на значения аргументов - для меня пока загадка. Может быть нас с Ins’ом и болтает как в восьмибальный шторм на борту клипера, но вас болтает не меньше. Наверное, я непонятно вопросы формулирую, если временами вы отвечаете совсем не на то, о чём был вопрос.

>> ввели понятия "этапы разработки". Никакого сарказма. Если найдете, где про это прочитать - сообщите. Буду рекомендовать другим.
Эммм… Только не говорите мне, что вы не знакомы с аббревиатурой RUP и термином "жизненный цикл разработки ПО"… В любом случае, можно начать с википедии. Ну а дальше по ссылкам. Можно курс в том же Luxsoft’е пройти. И даже не один…

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

>> Не знаю. Пишем предметно-ориентированный фреймворк.
Писать предметно-ориентированные фреймворки (да и фреймворки вообще) - это, я вам скажу, довольно непростая задача. Вы уверены, что для задачи моделирования цеховой логистики такой фреймворк потребен? Или, сформулирую вопрос иначе: на какой класс задач он должен быть ориентирован?

>> Да выбиваю из Вас (или "вас" в широком смысле) определить роль "контракта" в контексте этапов проектирования/программирования классов…
Не надо из "нас" (в широком смысле) ничего "выбивать". Роль контрактов в контексте проектирования/программирования классов ровно такая же, как в контексте проектирования/программирования других (более крупных) подсистем. Контракт очерчивает скоуп ответственности класса. Формулирует для разработчика конкретные цели и задачи по разработке класса. Позволяет грамотно его протестировать, добавить assert’шены, и т. п. По сути, контракт - это документация на класс - как его правильно использовать. Если вы смогли написать такую документацию, то вы сформулировали контракт. Скажу даже более строго: если вы смогли написать класс (каким бы он ни получился), то вы неявно этот контракт зафиксировали. Потому что (пусть даже подсознательно) в голове этот контракт у вас присутствовал, так как вы продумывали, как, в каком порядке, в каких контекстах будут/должны вызываться методы класса, с какими аргументами, как при этом будет эволюционировать состояние класса и т. д. и т. п. Я, честно говоря, не представля - как без знания всего этого (пусть и неявного) можно разработать что-то конкретное.

>> Или "предметно-подготовленные пользователи" вам мамой клянутся, что никогда-никогда не будут вызывать методы ваших классов с некорректными аргументами?
Оххх… "Предметно-ориентировнные пользователи" (под ними я понимаю программистов, которые будут использовать разработанные мною или вами классы оркоэльфов, например) - такие пользователи! Даже если сидят в соседней комнате… Они могут использовать те классы, которые им предлагаются, такими способами, которые и в страшном сне не привидятся. По этому (внимание!) ассерты на аргументы и инварианты ("заметьте, не я это предложил!" см. ваш комментарий №76) являются частью контракта. Чем жестче ваш код будет себя вести при нарушении предусловий и инвариантов - тем быстрей "предметно-ориентированный пользователь" найдёт свою ошибку и поправит её. Ну, на этапе разработки-отладки-тестирования, разумеется. И наоборот: чем аккуратнее ваш код будет скрывать подобное некорректное использование, тем более багливый получится результат.
Своей оговоркой я обращаю ваше внимание, что вы так или иначе используете знания о контрактах в процессе своей чистой и незамутнённой ООП-разработки. Просто, по-видимому, называете это как-то иначе. Но суть явления то от этого не меняется.

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