Будущее Делфи?

← →
Игорь Шевченко © (2009-04-03 02:13) [80]

oxffff © (03.04.09 00:49) [78]

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

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

Реймонда еще можешь почитать, который Эрик.

А у меня, извини, бисерный заводик закрылся.

← →
Riply © (2009-04-03 06:12) [81]

> [80] Игорь Шевченко © (03.04.09 02:13)
> А у меня, извини, бисерный заводик закрылся.

Я вижу кризис и Вас коснулся ? :)

← →
VirEx © (2009-04-03 09:48) [82]

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

а вобще будущее за прологом :-D

← →
palva © (2009-04-03 10:00) [83]

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

а будут вечно жить в наших сердцах...

← →
test © (2009-04-03 10:35) [84]

palva © (03.04.09 10:00) [83]
А что Дельфи как бы все? А когда похороны были?

← →
Anatoly Podgoretsky © (2009-04-03 11:09) [85]

> test (03.04.2009 10:35:24) [84]

"будут" это будущее время, значит "Будущее Делфи" есть.
Кра товарищи"

← →
clickmaker © (2009-04-03 11:21) [86]

> Кра товарищи

Кроетратное кра

← →
oxffff © (2009-04-03 11:27) [87]

> Игорь Шевченко © (03.04.09 02:13) [80]

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

← →
test © (2009-04-03 11:30) [88]

oxffff © (03.04.09 11:27) [87]
Вот взял и расстроил всячески Игоря он теперь не сможет: спать, есть, программировать....
)))

← →
Alkid © (2009-04-03 11:43) [89]

> oxffff © (02.04.09 23:03) [69]
> Почему С++ template нет в .NET?

Твоя неправда :) В С++/CLI поддерживаются И template И generics.

← →
Alkid © (2009-04-03 12:05) [90]

> VirEx © (03.04.09 09:48) [82]
> а вобще будущее за прологом :-D

"иба ваистену!" (с)

← →
oxffff © (2009-04-03 12:08) [91]

> Alkid © (03.04.09 11:43) [89]
>
> > oxffff © (02.04.09 23:03) [69]
> > Почему С++ template нет в .NET?
>
> Твоя неправда :) В С++/CLI поддерживаются И template И generics.
>

Я продолжаю настаивать, что идеалогии template нет в .NET,

То что в управляемом С++ можно использовать template style, так это заслуга не .NET, поскольку.

Comparing Templates and Generics
Key differences between generics and C++ templates:

Generics are generic until the types are substituted for them at runtime. Templates are specialized at compile time so they are not still parameterized types at runtime

The common language runtime specifically supports generics in MSIL. Because the runtime knows about generics, specific types can be substituted for generic types when referencing an assembly containing a generic type. Templates, in contrast, resolve into ordinary types at compile time and the resulting types may not be specialized in other assemblies.

Generics specialized in two different assemblies with the same type arguments are the same type. Templates specialized in two different assemblies with the same type arguments are considered by the runtime to be different types.

Generics are generated as a single piece of executable code which is used for all reference type arguments (this is not true for value types, which have a unique implementation per value type). The JIT compiler knows about generics and is able to optimize the code for the reference or value types that are used as type arguments. Templates generate separate runtime code for each specialization.

← →
Alkid © (2009-04-03 12:40) [92]

> oxffff © (03.04.09 12:08) [91]
> Я продолжаю настаивать, что идеалогии template нет в .NET,

"Идеологии template" нет и в системе команд процессора x86 :), что не мешает C++ с успехом поддерживать шаблоны в нативном коде. Ты прав в том смысле, что шаблоны - это фитча языка, а не платформы, в то время, как дженерики - фитча платформы. Замечу, кстати, что в Java всё наоборот - дженерики там являются именно фитчей языка, а не платформы.

Моя позиция, собственно, заключается в том, что никто не мешает иметь в .NET шаблоны и что их наличие никак не влияет на безопасность кода. Наличие шаблонов в С++ - тому доказательство.

Вопрос о том, какой из инструментов является предпочтительным, лично для меня остаётся открытым. Основное, с моей точки зрения, различие дженериков (если обобщить их Java и .NET реализации) заключается в том, что они не реализуют duck typing для своих аргументов, в то время как шаблоны реализуют. Это ограничение делает невозможным ряд интересных техник программирования.

← →
oxffff © (2009-04-03 13:05) [93]

> Alkid © (03.04.09 12:40) [92]

Я практически полностью разделяю твое мнение, за исключением того, что

> Моя позиция, собственно, заключается в том, что никто не
> мешает иметь в .NET шаблоны и что их наличие никак не влияет
> на безопасность кода. Наличие шаблонов в С++ - тому доказательство.
>

В том и дело, что при передаче параметров через разные сборки нельзя
гарантировать корректную передачу типа и проверить идентичность типа параметра метода и типа переданного в run time.
Я бы выразился это как наличие cross typing и inner typing(возможно имеется другой термин). То есть в пределах одного исполняемого модуля проверить идентичность типов и гарантировать ее можно.
В пределах разных нельзя.
Нет возможности проверить, что к типу применялись тот же набор type constructors в той же последовательности. Поэтому получив параметр из вне ты можешь только надеятся, что он именно того типа. А в случае с generics у среды есть возможность это проверить в run time при генерации native кода вызова. Поэтому здесь полная верификация. IMHO.

← →
Alkid © (2009-04-03 16:12) [94]

> oxffff © (03.04.09 13:05) [93]

Да, об этом я не подумал :-)

← →
Копир © (2009-04-03 19:47) [95]

>oxffff © (02.04.09 23:17) [72] :

Мудрецы!

Неужто так трудно у "а" прибавить "b"?

← →
oxffff © (2009-04-03 19:55) [96]

> Копир © (03.04.09 19:47) [95]

А я могу тебе предложить это сделать.
Покажешь как ты быстро это сделаешь?

← →
Копир © (2009-04-03 20:07) [97]

Будущее Delphi не зависит от той или иной популярности пакетов по мере
количества байтов создаваемого файла, по мере скорости компилляции, по мере
(не) трудности создания исходников.

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

Delphi - это дружественный пакет, позволяющий сделать "программу".
А не выпендриваться от того, что "программа" сделана на С++.

Delphi, как ни назхови, хоть пакетом визуальных компонетов, хоть "языком",
оне (Delphi) не станут хуже.

Пройдёт много лет.
Байкеры состарят себя.
Их мотоциклетные угодья сгниют.
Их негламурныя подруги постареют.
Их "язык" станет нонсенсом.
Подростки перестанут понимать устаревший slang.

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

Ему понравятся Delphi.
Потому, что там функцию можно назвать "Krestikinoliki".
И там, наверняка придумают новую компоненту с похожим названием.

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

И девочка будет в восторге!

А негламурный байкер, движущий тонны на своём С++, на своём мотоцикле,
позавидует наивному пользователю Delphi.

← →
Копир © (2009-04-03 20:10) [98]

>oxffff © (03.04.09 19:55) [96] :

a:= a+b;

← →
clickmaker © (2009-04-03 20:14) [99]

> А негламурный байкер, движущий тонны

если тонны, то это уже негламурный дальнобойщик

← →
oxffff © (2009-04-03 20:21) [100]

> Копир © (03.04.09 20:10) [98]

Это не то.
Речь шла о том, как ты предлагаешь в run time компилятору быстро развернуть обобщенный код вида?

AddExpression<T,U>=class
class function Expression(const a:T;const b:U):T;static;
end;

class function AddExpression<T, U>.Expression(const a: T; const b: U): T;
begin
result:=a+b;
end;

← →
Копир © (2009-04-03 20:29) [101]

>oxffff © (03.04.09 20:21) [100] :
>Это не то.

Сергей, ну чего Вы меня грузите?
Я ваще не программист.

Я так. Писатель :)

← →
31512 © (2009-04-03 20:44) [102]

> Игорь Шевченко © (03.04.09 02:13) [80]

В книге Фаулера "Архитектура корпоративных программных приложений" 2006 г. ИСПРАВЛЕННОЕ ИЗДАНИЕ на стр. 28 (Введение) он лаконично уклоняется от дачи чёткого определения термина "архитектура"
Цитата:
"Одно из странных свойств, присущих индустрии программного обеспечения, связано с тем, что какой-либо термин может иметь множество противоречивых толкований. Вероятно, наиболее многострадальным оказалось понятие архитектура (architecture). Мне кажется, оно принадлежит к числу тех нарочито эффектных слов, которые употребляют
ся преимущественно для обозначения чего-то, считающегося значительным и серьезным."

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

И если

> Игорь Шевченко © (02.04.09 23:37) [74]

> Один и тот же проект был написан на С и на С++ (ну так вышло),
> в С нет виртуальных методов, они были успешно эмулированы
> на С, как таблицы указателей на функции (примерно также,
> как карты сообщений в MFC, механизмы достаточно похожи).
>

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

← →
Игорь Шевченко © (2009-04-03 21:09) [103]

31512 © (03.04.09 20:44) [102]

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

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

← →
31512 © (2009-04-03 21:28) [104]

> Игорь Шевченко © (03.04.09 21:09) [103]

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

← →
Игорь Шевченко © (2009-04-03 21:49) [105]

31512 © (03.04.09 21:28) [104]

> Значит это не архитектурное решение.

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

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

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

← →
oxffff © (2009-04-03 21:57) [106]

> Игорь Шевченко © (03.04.09 21:09) [103]
> В моем понимании - архитектура приложения - это совокупность
> частей и интерфейсов между ними (не механизмов реализации
> взаимодействия, в данном случае неважно, посылает ли одна
> часть другой оконное сообщение или вызывает другую часть,
> как метод объекта),

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

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

Рассмотрим любую произвольную архитектуру. Это по вашему определению набор частей и интрерфейсов между ними. Вы намеренно отказываетесь от деталей реализации. Тогда рассматривая произвольную часть архитектуры можно ее также рассмотреть как части 2 уровня и интрерфейсы между ними.
Рекурсивно спускаясь + обобщая на все архитектуры можно заключить следующее - все архитектуры идентичны. поскольку все состоит из частей и интерфейсов между ними. А это извините бред.

← →
oxffff © (2009-04-03 22:15) [107]

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

Здесь смешалось все кони, люди.

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

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

← →
31512 © (2009-04-03 22:16) [108]

> Игорь Шевченко © (03.04.09 21:49) [105]

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

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

> 31512 © (03.04.09 22:16) [108]

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

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

to 31512

> oxffff © (03.04.09 22:31) [109]
> контракт это обобщенное решение,

Далее если рассмотреть само понятие контракта можно рассмотреть как обязанность одного перед другим. Однако технически сам контракт(строительный элемент) как тип является строительным блоком. В одном яыке это может быть интерфейсы, в другом классы, в третьем вызовы через оператора телефона со своим контрактом, .... . И хотя все это будет контракты мы не будем забывать что каждый из них обладает своим индивидуальным устройством не совместимым с другим.
И eсли есть узлы А и B, которые связаны контрактом C.
То в одной библиотеке сам контракт это COM интерфейс, а в другом это dynamic method. И хотя это все конракты, архитектурно они различны. А значит и библиотеки архитектурно различны, но обладают сходным решением. Надеюсь теперь ты понял меня.

31512 © (03.04.09 22:16) [108]

> Думаю, нет, не зависит. Главное, чтобы они были написаны
> по правилам для таких плагинов.

Я к тому же. Тот же Фаулер, те же Гамма, Влисидис и сотоварищи, демонстрируя аржитектурные решения не привязывают их к какому-то конкретному языку, а то, что приводят примеры на С++ или Smalltalk (или на C# и Java у Фаулера) - ну надо же на чем-то приводить приводить примеры, чтобы пояснить мысль. Безусловно, часть каких-то решений (из тех же паттернов банды четырех) уже может быть встроена в какой-то конкретный язык, но архитектура от этого не меняется. Просто используются встроенный средства для тех или иных архитектурных решений.

Собственно весь спор начался с утверждения [41], что архитектура прогибается под возможности языка, если что :)

> oxffff © (03.04.09 22:31) [109]

Поскольку пост в мой адрес - отвечу.

> Язык здесь не причем. Тебе пытаются подменить понятия.

Никто, мне ничего подменить не пытается. Мысль я твою понял.
Есть система А. Она ожидает, что в каждом плагине будет экспортирована функция
function Attach: TAttachResult;stdcall;
TAttachResult - определён архитектурой.
Понятно, что не получив эту функцию, система отвергнет плагин, равно и в том случае, если TAttachResult не будет соответсвовать соглашению.
Просто ты хочешь сказать, что содержание TAttachResult и есть детализация, которой пренебрегать нельзя. Так? Если так, то это никак не нарушает определения в [103].

> Игорь Шевченко © (03.04.09 22:44) [111]

> Собственно весь спор начался с утверждения [41], что архитектура
> прогибается под возможности языка, если что :)

Иногда "архитектурят" с учётом возможностей языка. По мне, так, тут бяка может случиться.

Еще одно определение (длинное слегка, приходится ужимать, надеюсь, без потери деталей):

"Архитектура должна определять основные компоненты программы. Каждый компонент является классом или набором классов классов/методов, которые в совокупности реализуют высокоуровневые функции программы, такие как взаимодействие с пользователем, отображение WEB-страниц, инкапсуляция бизнес-правил или доступ к данным.
Архитектура должна четко определять ответственность каждого компонента. Компонент должен иметь одну область ответственности и как можно меньше знать об областях ответственности других компонентов. Архитектура должна определять правила коммуникации для каждого компонента. Она должна описывать, какие другие компоненты данный компонент может использовать непосредственно, какие косвенно, а какие вообще не должен использовать.
Аритектура должна описывать основные классы приложения, иерархии классов, а также изменения состояний и время существования объектов.
Если система достаточно велика, архитектура должна описывать организацию классов в подсистемы."

...
Ну и еще на пару страниц

(с) Стив МакКоннел, "Совершенный код"

> 31512 © (03.04.09 22:49) [112]

Я хочу сказать что есть решение, и есть архитектура этого решения.
Решение может быть общим, но у него будет все равно конкретная архитектура.

Что касаемо системы А. Она ожидает экспортированную функцию С.
А теперь представь систему B, которая тоже ожидает экспортированную функцию С. НО!

в систему A она передается передачей адреса stdcall функции.
а в систему B она передается с помощью объекта с динамическим методом.
И там и там есть контракт С, но реализован он по разному.
Решения сходны, но архитектурно различны, поскольку архитектуры не совместимы(нельзя передать С из решения B, в решение A).
То есть возможости средства реализации накладывают отпечаток на архитектурное решение. И коли тут уже упомянули GOF, то фабрика класса С++ и использование метакласса в Delphi следуют одной и той же цели - динамическому созданию объекта.
Это два сходных решения, но архитектурно различных.

> Игорь Шевченко © (03.04.09 23:00) [114]

МакКоннела не читал. Только разобрался с тензорами инерции и сил трения, своей модели атм. аэрозоля. Теперь нахожусь в состоянии исследования зависимости сечения поглощения от длины волны и уравнения теплового баланса. Вот чувствую, что придётся после защиты диссертации, читать и МакКоннела, и Реймонда, и Э. Гамма Р. Хелма Р. Джонсона Дж. Влиссидеса
Так что я нахожусь в базисном состоянии Винни-Пуха:
"Ты не забывай, что у меня в голове опилки. Длинные слова меня только расстаивают..." .
:-)

← →
kaif (2009-04-04 00:57) [118]

← →
Городской Шаман (2009-04-04 01:20) [119]

Это фигня. Вот здесь .ПТУшники с Джавистами схлеснулись по поводу виртуальных методов.
http://www.developers.org.ua/forum/topic/463/page/2#post-4853

Оказывается, виртуальные методы есть зло?

> Городской Шаман (04.04.09 01:20) [119

Как это фигня? То есть ты хочешь сказать, что такого нет?

Будущее Делфи? Найти похожие ветки