куда катится мир? в частности Delphi а за ним и Лазарус

[iN0k]

Но "аналогичный" обьект данных в Дельфи есть, и это object?

[Sergei I. Gorelkin]

record и object не аналогичны. Внутренняя структура у record предсказуема и бинарно совместима с другими языками, у object - нет.

object в FPC не является устаревшим, поддерживается, в нем исправлен ряд ошибок, имеющихся в его аналоге из Дельфи.

ps. А сборщик мусора к Дельфи уже приходил, в районе 2002 года (Delphi 8 ), если память не изменяет. После чего контора сменила два названия и до сих пор нельзя сказать, что до конца оклемалась.

[alexey38]

Текущая реализация методов у записи не меняет бинарную структуру записи, а только добавляет неявные параметры у самого метода, и неявно выполняет аналог with RecName do.
В некоторых случаях, такая форма синтаксиса бывает удобнее. Вернее сказать, что процедуры, обрабатывающие только одну запись выглядят синтаксически коряво (сам код).

Насчет того, что нужно ли бояться, что вставят ВМТ, то если бояться, то всего. А вдруг завтра begin ... end, заменят на { ... }? А вдргу запретят процедуры? А вдруг еще что-то произойдет?

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

[iN0k]

object в FPC не является устаревшим, поддерживается, в нем исправлен ряд ошибок

а какие ошибки были исправленны?
пуф или на словах
поиск на bugs.freepascal.org по слову object дает ~3000 (уровень знания англ. и скорость работы сайта не распологает к просмотру каждого ), а при фильтре "FPC core .." пусто

[Sergei I. Gorelkin]

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

[iN0k]

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

Спасибо за столь быстрый ответ

[stikriz]

Вопрос: зачем добавили методы в рекордах?

Лучше задать вопрос так:
- Рекорды без методов - это те же самые рекорды? Могу я сделать GetMem, FreeMem, Move так же как и раньше?
И тогда половина душевной боли поутихнет.

[iN0k]

Насчет того, что нужно ли бояться, что вставят ВМТ, то если бояться, то всего. А вдруг завтра begin ... end, заменят на { ... }? А вдргу запретят процедуры? А вдруг еще что-то произойдет?

согласен. "Волков бояться в лес не ходить". НО при походе в лес и знании что там много-много волков, глупо не готовиться к встрече с ними
если Дельфи идет в сторону Джава-Руби то и фиг на него
если Лазарус пойдет за Дельфи ... это будет печально

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

с поправкой на комерческие проекты согласен. Там решения принимают, скорее всего, больше в угоду своим (корпаративным) интересам или Манагеры волевым методом (мода, мнение-желание конкретного чела). В качестве примеров наверно можно притянуть ранние Офисные пакеты от Мастадонтов индустрии . Однако ж, ну не полные дятлы же там сидят, и продавить освсем идиотское решение ну очень сложно, следовательно обсмеять решение и несогласиться с ним можно при условии понимания мотивов и целей.

Это не та тема, которая годами исследуется и плавно внедряется.

в опенСурсе хочется верить что это всетаки ТЕМА

поэтому вопрос для меня всетаки открыт:
зачем добавили методы в рекордах?

неудовлетворенность данными ответами следующая:

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

в условиях отсутствия наследавания объединение данных и функций мне кажется странным, вот тните меня носом, потому что фантазия дальше "ненужных" банальныйх гетер/сетер не идет (пример хачу ).
А процедуры, на мой взгляд, выглядят логично и самое главное ЯВНО.

Я подозреваю, что в delphi это сделали для того, чтобы поддерживать аналогичный тип объекта данных из .NET Framework

подозрения ... неужто так?

PS

Искать вззаимосвязи изменений - это гадание на кофейной гуще и не более.

не согласен. искать НАДА

Добавлено спустя 2 минуты:

Лучше задать вопрос так:- Рекорды без методов - это те же самые рекорды? Могу я сделать GetMem, FreeMem, Move так же как и раньше?И тогда половина душевной боли поутихнет.

согласен. на так важен рекорд как поинтер на него )))

Добавлено спустя 4 минуты 12 секунд:
на счет GetMem, FreeMem, Move ...
дамется никуда это не уйдет

степень моей боязни будущего в моих постах преднамеренно утрирована

[alexey38]

неудовлетворенность данными ответами следующая:
alexey38 писал(а):
В некоторых случаях, такая форма синтаксиса бывает удобнее. Вернее сказать, что процедуры, обрабатывающие только одну запись выглядят синтаксически коряво (сам код).
в условиях отсутствия наследавания объединение данных и функций мне кажется странным, вот тните меня носом, потому что фантазия дальше "ненужных" банальныйх гетер/сетер не идет (пример хачу ). А процедуры, на мой взгляд, выглядят логично и самое главное ЯВНО.

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

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

2. Косметический. Для процедуры, обрабатывающей только одну запись, причем работая с многими полями, то экономим на 3-х строках: with do, begin, end.

[Sergei I. Gorelkin]

О направлении движения можно не строить предположений, идет совершенно безумное и бездумное копирование .net, начиная от названий (EArgumentOutOfRangeException -- в то время как в раннем Дельфи ни один класс исключений, кроме базового Exception, не содержал в названии слова Exception, вместо него применялся префикс "E"), сигнатур методов (TEncoding.GetChars(const Bytes: TBytes; ByteIndex, ByteCount: Integer)) -- в то время как в Паскале это должно было бы выглядеть как TEncoding.GetChars(const bytes: array of byte), причем этот подход ничуть не менее "безопасен", и заканчивая целыми классами и фичами языка.

И это, в общем-то, не так уж и плохо - те, кому надоел .net, смогут перейти на FPC и найти много знакомых вещей

[Vapaamies]

object в FPC не является устаревшим, поддерживается, в нем исправлен ряд ошибок, имеющихся в его аналоге из Дельфи.

В Delphi 6/7 можно было написать так:

Код: Выделить всё

type
  TMyObj = object
    class function ClassValue: Integer;
  end;


Но этой функции всё равно передавался на вход несуществующий Self! В FPC как?

[Sergei I. Gorelkin]

Так же, вместо self передается nil. Но к class-методу можно применять модификатор static, тогда self передаваться не будет.

[iN0k]

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

итак:
1. "куда катится мир? в частности Delphi":

идет совершенно безумное и бездумное копирование .net

2. "а за ним и Лазарус":
ответ звучит как в противовес Delphi

смогут перейти на FPC и найти много знакомых вещей

В итоге, для себя я получаю:
1. Подтверждение смутных догадок сводящихся к фразе "с Delphi мне не по пути".
2. Поиск альтернатив.

И тогда, хочется задать следующий вопрос:
"Когда Lazarus|FPC полностью оторвется от своего старшего брата Delphi и пойдет своим путем. Произойдет ли это."

[SSerge]

iN0k
Lazarus/FPC оторвется от Delphi и пойдет своим путем только тогда, когда Delphi перестанет существовать.

И он нифига не старший брат - и не брат вовсе, скорее фетиш, знамя и икона.
По "братству" скорее ближе C# и Delphi, у них биологический папа практически один и тот же.

[stikriz]

Разработчики Lazarus очень неплохо экономят время и разгружают мозги, когда не парясь тырят интерфейсы классов у Delphi. Уйти от этого не так-то просто. Копи-пасте - это наше все! Тем более, что забот хватает в реализации кросплатформенного по самое нехочу... Поэтому, Delphi - это тот кто протаптывает дорогу. Можно отстать - не проблема. Но, если уйти далеко в сторону, то резко затормозится разработка. Да, и всегда проще на основе хорошего делать лучше, чем идти своим непротоптаным путем.