Delphi vs All

Доброе время суток.
У Delphi, немало недостатков. Например, невероятная глючность, и IDE, и сам язык и получившиеся программы, постоянно выкидывают какие-нибудь коленца, причем совершенно непредсказуемые.
Но! У Delphi есть преимущество: она предоставляет пользователю готовый набор компонент, в то время как написание проекта на "более серьезных языках", напоминает то, как если бы вы строили дом и сами бы делали кирпичи, вырезали оконные рамы, дули бы стекла для окон и так далее.

0

С того, что оно имеет смысл во всей задаче, следовательно глобально. Поэтому прятать его в локальную переменную функции WinMain и таскать через параметры всех подзадач безграмотно. Переменные функции WinMain локальны в функции WinMain и предназначены для данных, имеющих смысл только в подзадаче инициализации приложения и не более того. Или у тебя функция main? Сути это не меняет.

0

Сообщение от taras atavin Количество существующих на данный момент и известных человечеству парадигм ограничено, что делает допустимой логическую индукцию. Моё умозаключение индуктивно,

Прежде чем делать индукцию, подтверди для малого количества парадигм. Я весь внимание.

Добавлено через 2 минуты

Сообщение от taras atavin С того, что оно имеет смысл во всей задаче, следовательно глобально.

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

0

Сообщение от dondublon Прежде чем делать индукцию, подтверди для малого количества парадигм. Я весь внимание.

Читай выше.

0

Сообщение от taras atavin Читай выше.

Не вижу. Само утверждение вижу, как получилось - нет. Подскажи?

0

Сообщение от dondublon Другой вопрос, что если ты допустил такую потребность - то ты не умеешь обращаться с программированием.

Не факт. Задача - моделировать поведение технологического агрегата. Он и будет объектом. Сам объект глобален, так как имеет смысл во всей задаче, а целиком систему управления заводом я не делаю. Особенность постановки, не более.

0

Сообщение от taras atavin Задача - моделировать поведение технологического агрегата. Он и будет объектом. Сам объект глобален, так как имеет смысл во всей задаче,

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

0

Сообщение от dondublon Не вижу. Само утверждение вижу, как получилось - нет. Подскажи?

Функциональная и декларативная перебраны. В ООП существуют локальные переменные методов. В процедурной есть локальные переменные подпрограмм. На низком уровне есть локальная память отдельного вычислителя, решающего конкретную подзадачу. Его может не быть, но это частность, но вообще локальность возможна. Итого 5 парадигм, ни одна не исключает локальности.

Добавлено через 5 минут

Сообщение от dondublon При правильном разбиении на объекты обязательно будет что-то, не видящее агрегат. Не привязанные к агрегаты - события, вывод каких-то сообщений, решение математических задач.

Задача - моделировать АКОС. Ровно 1. Будет много чего, даже при не правильной декомпозиции не видящего электроды, а электроды не увидят донную фурму. Но то, что не видит ни весь АКОС, ни его часть, не относится к задаче его моделирования. АКОС - глобальный объект, в программе он называется LadleFurnace, остальные объекты - его части. Матрица же коэффициентов СЛАУ при моделировании распределения амплитуд потенциала в металлической ванне локальна по смыслу задачи. И находится внутри метода simulate объекта LadleFurnace.

0

Сообщение от taras atavin Функциональная и декларативная перебраны. В ООП существуют локальные переменные методов. В процедурной есть локальные переменные подпрограмм. На низком уровне есть локальная память отдельного вычислителя, решающего конкретную подзадачу. Его может не быть, но это частность, но вообще локальность возможна. Итого 5 парадигм, ни одна не исключает локальности.

ООП включает специальный принцип, по которому строится видимость. То есть, принцип говорит, "видимость должна быть такая-то, с ней надо поступать так-то". Значит, парадигма имеет отношение к области видимости.

Итого - общее утверждение неверно.

0

Нет. Раз нет ни одного вида областей видимости, исключаемого хотя бы одной парадигмой, то одно к другому не относится. private, public и protected лишь дополняют слово "видимость" ещё одним значением, но понятие видимости не уникально для ООП.

Добавлено через 6 минут
Только в алгоритмической парадигме существует иллюзия исключения локальных переменных, разрушаемая сразу же, если вспомнить что:
1. Один алгоритм может быть вложен в другой.
2. Процедурные языки - подвид алгоритмических.

0

Сообщение от taras atavin Нет. Раз нет ни одного вида областей видимости, исключаемого хотя бы одной парадигмой, то одно к другому не относится. private, public и protected лишь дополняют слово "видимость" ещё одним значением, но понятие видимости не уникально для ООП.

Ну как же нет, когда сама парадигма говорит о том, какие бывают области.
ООП говорит, есть область-объект, и там - private и т.д.

0

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

Добавлено через 3 минуты

Сообщение от dondublon Ну как же нет, когда сама парадигма говорит о том, какие бывают области. ООП говорит, есть область-объект, и там - private и т.д.

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

Добавлено через 7 минут
Парадигма - это всего лишь подход к программированию/проектированию, а декомпозиция возможна при любом подходе и при любом подходе могут быть локальные и глобальные константы и переменные. А в ООП могут быть ещё и локальные и глобальные объекты. Даже ПЗУ на перемычках ввиде кабелей и программирование путём его ручного заполнения не исключает ни одной из возможных видимостей, включая и private с пабликом: отдельный вычислитель может заниматься не только вычислением функции/процедуры, но и брать на себя всю реализацию объекта.

Добавлено через 7 минут
Даже ПЗУ на перемычках ввиде кабелей и программирование путём его ручного заполнения не исключает ни одной из возможных видимостей, включая и private с пабликом: отдельный вычислитель может заниматься не только вычислением функции/процедуры, но и брать на себя всю реализацию объекта и иметь два устройства памяти, одно для private, а второе подключенное к глобальной шине и предназначенное для хранения public полей. То, что так не делается, сути не меняет. В принципе возможно, значит парадигма низкоуровневого программирование допускает.

0

Сообщение от taras atavin Тем не менее ООП лишь дополняет термин вторым значением, изменяя,

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

Сообщение от taras atavin Ты этого не понимаешь, значит не понимаешь самого слова "парадигма" и не готов к изучению ООП.

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

0

У меня и делфа не глючит. Зато глючит лазарус, а язык то тот же. Глюк уже обнаружен и уже понятно, как с ним бороться: если объекты класса TMemo имеют visible=flase, или находятся на скрытой форме, то их нельзя использовать для генерации и хранения постфиксных выражений и вместо стека чисел, так как в результате выражение может быть вычислено не правильно. Можно ли использовать только по некоторым из этих назначений, но не по всем названным сразу я не проверял. Если я так оставлю, то виноват буду я в том, что недоотладил, а не разработчики лазаруса, но глюк вылез из лазаруса, так как при видимых мемах глюков нет, значит мой текст правильный, а глюк именно от не учёта ошибки в лазарусе.

Добавлено через 6 минут

Сообщение от dondublon видимость protected может быть только в ООП. Т.е. у этой парадигмы свой ответ на то, что такое "область видимости". Так что я прав.

Отдельный составной вычислитель, реализующий весь класс и программно выдающий данные остальным частям вычислительной системы, или имеющий 2 памяти на разных шинах, одна локальная, другая выходит наружу, но имеющий в своём составе часть, являющуюся таким же отдельным вычислителем, но отвечающем за производный класс элементарно обеспечит и protected на низком уровне. Определены все 3 только в ООП, но реализуемы даже при ручной пайке ПЗУ на перемычках и составлении программы сразу в числовых кодах.

Добавлено через 4 минуты
Резюме: видимость в этом значении может быть вырвана из контекста и перенесена в другую парадигму.

0

Сообщение от taras atavin но реализуемы даже при ручной пайке ПЗУ на перемычках и составлении программы сразу в числовых кодах.

костыли не считаются, ибо они - не часть парадигмы

0

Не часть, но и не запрещены явно.

0

Да-да-да. Старая отмазка - это не инструмент плохой, это у тебя руки кривые. Старо и скучно.

0

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

0

Сообщение от taras atavin Инструмент косой, но если очень охота, а руки прямые, то можно не к месту и без толку прилепить отдельные свойства хорошего.

А нахрена кривым мастерком и тупым ножом орудовать?

0

Так я к этому не призываю, речь о том, что в топор проект избы не заложен.

0

Сообщение от taras atavin Так я к этому не призываю, речь о том, что в топор проект избы не заложен.

Боюсь что Delphi - элемент малость посложнее топора.

0