Python vs Delphi

Цитата mo3r @ 11.08.06, 11:15

э-ээ.. Этот код отличается от моего. Нужно передать в my_func2 то, что нам вернула my_func, а затем это удалить. Интересно, как это будет выглядеть с with? И сколько строчек он будет занимать? А если аргументов --- не один, а пять?

Да ты что

type
  MyClass = class
    function GetThis: MyClass;
    property This: MyClass read GetThis;
  end;
 
function MyClass.GetThis: MyClass;
begin
  Result := Self;
end;
 
function my_func: MyClass; begin result := MyClass.Create(); end;
 
procedure my_func2(mc: MyClass); begin ... end;
 
begin
  with my_func do
  try
    my_func2(this);
  finally
    free;
  end;
end.

Цитата mo3r @ 11.08.06, 11:15

Можно примерчик?

И то же самое с интерфейсами:

type
  IMyClassInt = interface
    ...
  end;
  
  TMyClass = class(TInterfacedObject, IMyClassInt)
    ...
  end;
 
function my_func: IMyClassInt; begin result := MyClass.Create(); end;
 
procedure my_func2(mc: IMyClassInt); begin ... end;

Цитата Smike @ 11.08.06, 13:03

Да ты что

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

Цитата mo3r @ 11.08.06, 12:59

А как у этой штуки с наследованием --- ведь TInterfacedObject --- это класс, не так ли? А это уже не даст отнаследовться от других классов.

Smike, а на это что скажешь?

Цитата mo3r @ 11.08.06, 13:12

Smike, а на это что скажешь?

А что мешает базовый класс от интерфейсного объекта унаследовать? TInterfacedObject - это такой же объект, только со счетчиком ссылок. Классы VCL и так интерфейсные:

  TComponent = class(TPersistent, IInterface, IInterfaceComponentReference)

Цитата Smike @ 11.08.06, 13:20

А что мешает базовый класс от интерфейсного объекта унаследовать? TInterfacedObject - это такой же объект, только со счетчиком ссылок. Классы VCL и так интерфейсные:

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

Цитата best_lamer @ 11.08.06, 12:35

Таким образом со счетом (0:00:03) против (0:00:28) те 3 сек. против 28 сек. победил (фанфары барабаны) Delphi Ура товарищи!

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

Цитата mo3r @ 11.08.06, 13:27

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

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

Цитата Smike @ 11.08.06, 13:03

Да ты что

А если таких аргументов, скажем, два, а?

Цитата best_lamer @ 11.08.06, 12:35

PS С факториалом я не туда поглядел!

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

Цитата best_lamer @ 11.08.06, 13:35

У кого есть желание проверить точнее милости просим

Что, так долго считает?

Добавлено 11.08.06, 13:41

Цитата linuxfan @ 11.08.06, 13:31

А если таких аргументов, скажем, два, а?

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

Сейчас подмешиваемые (Mix-in) классы вспомниать начнем...

Цитата Smike @ 11.08.06, 13:39

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

Ясно. Значит -- никак. Ну не очень-то и надо.
В C++ лямбда функций ведь нет (костыль, кажется, в boost положили?)

Цитата linuxfan @ 11.08.06, 13:47

В C++ лямбда функций ведь нет (костыль, кажется, в boost положили?)

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

Цитата linuxfan @ 11.08.06, 13:29

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

Полностью согласен! Я сам и не ожидал того что Python будет быстрее хотя это было бы клево. Просто я хотел оценить во сколько раз интерпретируемые языки медленнее. Оценил приблизительно раз в 10 проигрыш по скорости исполнения кода.

Добавлено 11.08.06, 13:54

Цитата Smike @ 11.08.06, 13:39

Что, так долго считает?

Ты вначале сделай нормальный факториал в целых а потом поговорим дальше идет?

Цитата mo3r @ 11.08.06, 12:59

Дельфы под рукой нету, нельзя ли показать вывод от этого приложения?

Вывод как и должен быть. Увы, из консоли не копируется у меня, пишу:

Цитата

Foooo!
Destroy

И ждет Enter на readln, разумеется.

Цитата mo3r @ 11.08.06, 13:27

Цитата (Smike @ Сегодня, 17:20)
А что мешает базовый класс от интерфейсного объекта унаследовать? TInterfacedObject - это такой же объект, только со счетчиком ссылок. Классы VCL и так интерфейсные:

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

Ну млин. Интерфейс я ввести могу на любом уровне иерархии. Я использовал TInterfacedObjetc потому, что там реализованы три метода IInterface.
Вот как раз и вводятся интерфейсы:

Цитата Smike @ 11.08.06, 13:20

TComponent = class(TPersistent, IInterface, IInterfaceComponentReference)

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

Цитата mo3r @ 11.08.06, 12:59

Цитата (Romkin @ Сегодня, 16:36)
type IFoo = interface procedure FooFoo; end; //Реализация TFoo = class(TInterfacedObject, IFoo) protected procedure FooFoo; public destructor Destroy; override; //Для иллюстрации даем сообщение end;

Да, это "очень удобно и немногословно".

Да, это очень удобно. А многословно или нет - кто-то может считать, что многословно. И что с того? Написано все, что нужно и так как должно. Это - компонент-ориентированное программирование уже, следующая стадия ООП. Интерфейс описывается отдельно, реализация - отдельно. Ясно, что у одного интерфейса может быть любое количество реализаций и один класс может реализовать несколько интерфейсов.
Что такое компонентная модель - читайте книгу Дональда Бокса "Сущность технологии COM". Там он в первой главе очень популярно объясняет что это. Все, правда, на С++.

Добавлено 11.08.06, 14:17

Цитата linuxfan @ 11.08.06, 13:29

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

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

Цитата linuxfan @ 11.08.06, 12:21

все плюсовые библиотеки либо костыли для действий, не предусмотренных стандартом

В этом выражении надо убрать слово "плюсовые"

Цитата linuxfan @ 11.08.06, 12:21

либо просто врапперы над сишными

А в Python иначе?

Цитата linuxfan @ 11.08.06, 12:21

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

Понятие "реально нужные вещи" весьма относительно. Мне вот не нужен ни один python'овский пакет. И сам python ни к чему.