OberonCore https://forum.oberoncore.ru/ |
|
Массив https://forum.oberoncore.ru/viewtopic.php?f=35&t=5991 |
Страница 3 из 4 |
Автор: | ilovb [ Суббота, 14 Январь, 2017 13:39 ] |
Заголовок сообщения: | Re: Массив |
Проперти - это которые геттеры/сеттеры? Всегда считал, что эта фича позволяет навешивать контроль обращения к полям без изменения клиентского кода. Вроде нехилый такой профит. Избавляет от мучений с выбором: * Сделать поле публичным * Закрыть обращение к полю методом С точки зрения клиента, он просто обращается к публичному полю (R.P := X; и X := R.P;) |
Автор: | ilovb [ Суббота, 14 Январь, 2017 13:54 ] |
Заголовок сообщения: | Re: Массив |
Александр Ильин писал(а): Kemet писал(а): А во в Дэлфи они очень активно используются. Это точно. Например, так:Код: procedure GreetUser(firstTime: Boolean); const greeting: array[Boolean] of string = ("Hello!", "Hello again!"); begin Writeln(greeting[firstTime]); end; Зря параметр булевский. Нужно считать сколько раз было приветствие. На >1000 раз выдавать "what's up bro?!" |
Автор: | Илья Ермаков [ Суббота, 14 Январь, 2017 16:35 ] |
Заголовок сообщения: | Re: Массив |
Info21 писал(а): Про этимологию -- это слишком умно, но штука мощная, только недоделанная (припоминается, что в документации это где-то сказано). Да нет, тут речь не про ББ-шные проперти, а про "общечеловеческие". Как замена геттерам и сеттерам, когда обращаешься как к полю объекта, а реально там потом можно навесить перехватывающие обработчики на чтение и изменение. Реально, при наличии экспорта только на чтение (которого не было в тех языках, где изначально появились проперти, в Дельфи, и в ВизуалБарсике, кажется), они уже менее полезны. С++-серы их не имеют - и не парятся. Обычно сразу чётко ясно, либо это пассивные данные, не расширяемый тип - и можно высунуть на чтение, либо в любом случае это придётся порождать (property любого абстрактного объекта, РАЗУМЕЕТСЯ, будет реализовываться вычислимо через метод потом) - и тогда сразу заводить геттеры и сеттеры. Представить себе, что сразу не было ясно, будет ли опосредование методами - или это просто поле, - такое представить трудно. В библиотеках аля VCL, построенных на глубоком наследовании реализации, наверняка какую-то вспомогательную архитектурную роль property могут дать. Типа, ввели где-то на 3 уровня ниже, а потом выше как-то модифицируем поведение. Навешиваем обработчики onChange, допустим (т.е. каждый уровень наследования прицепил обработчик и следит за изменением, это построже и понадёжнее, чем такое же мутить через перегрузку метода, с правильным порядком вызова предков и т.п.). Но при гомогенных ирерархиях (ABSTRACT + закрытая реализация + рост системы через композицию, а не наследование) уже и неясно, нафига козе такой баян. Да и в случае с наследованием реализации за счёт архитектурных средств КП можно убрать проблемы правильной перегрузки. |
Автор: | Trurl [ Суббота, 14 Январь, 2017 17:36 ] |
Заголовок сообщения: | Re: Массив |
Это же просто способ замаскировать вызов процедуры под присваивание. А применение всемунайти можно. |
Автор: | ilovb [ Суббота, 14 Январь, 2017 18:08 ] |
Заголовок сообщения: | Re: Массив |
Илья Ермаков писал(а): Представить себе, что сразу не было ясно, будет ли опосредование методами - или это просто поле, - такое представить трудно. Хм. А мне вот очень легко представить. Бывает что ТЗ меняется раз по пять в процессе реализации. Так что в самом начале крайне редко все бывает ясным (даже если кажется что все ясно). Потому я считаю самым надежным решением - не делать публичных полей вообще. Проперти в данном случае являются хорошим компромиссом. С моей стороны все сделано методами, а со стороны клиента это поля. Все довольны ps Ну и само наличие пропертей в языке делает безболезненным переход от публичных полей к методам |
Автор: | Kemet [ Воскресенье, 15 Январь, 2017 11:38 ] |
Заголовок сообщения: | Re: Массив |
Илья Ермаков писал(а): Реально, при наличии экспорта только на чтение (которого не было в тех языках, где изначально появились проперти, в Дельфи, и в ВизуалБарсике, кажется), они уже менее полезны. С++-серы их не имеют - и не парятся. В Обероне экспорта только для чтения не было, он был заимствован позднее из Оберона-2. А в Обероне-2 он, видимо, и появился по причине отсутствия этих самых "пропертей" и защищенных членов - реализовать их было несколько сложнее и требовало введения новых сущностей и изменения старых, что противоречило Виртовскому подходу - "не смог за полчаса реализовать, значит это не нужно". В общем-то, для учебного языка/компилятора это правильный подход, иначе студиозусы просто не смогут реализовать некую штуку за отведенное им время.Впрочем, в Дельфи в качестве "сеттера/геттера" может использоваться не только метод, но и поле. В целом, такой подход гибче и мощнее., а сами пропетри позволяют стандартизировать и автоматизировать работу. Наличие свойств в Дельфи позволило существенно упростить поддержку (де)сериализации компонентов. Да в общем-то компилятор берет на себя большую часть работы, уменьшая количество ошибок. Что касается С++серов, то лни явно парятся, так как велосипеды появляются вновь и вновь, а microsoft реализовала их поддержку ( очередным велосипедом, но как я понимаю, уже на уровне компилятора ). А простейшую имитацию можно легко сделать, так как в С++ поддерживается перегрузка методов. Это не проперти, да, но зато просто. Или воспользоваться средствами языка ( перегрузка операций ) сделать псевдопроперти га базе структур или классов. В Обероне так не получится и приходится всё тащить в компилятор или делать нечто монструозное, как, например, в А2, с постоянной возможностью где-то чего-то забыть. Да из-за этих недопропертей ( ну или из-за такой реализации их ) в А2 есть некоторые проблемы с ними ( и с производительностью, в связи с чем рядом с проперью лежит и соответствующиее поле с для кеширования значения проперти, и с взаимодействием и не совсем понятно, как соединить Формы созданные в Билдере с кодом (обработчики и тп ), тогда как в Дельфи таких проблем нет). Цитата: Обычно сразу чётко ясно, либо это пассивные данные, не расширяемый тип - и можно высунуть на чтение, либо в любом случае это придётся порождать (property любого абстрактного объекта, РАЗУМЕЕТСЯ, будет реализовываться вычислимо через метод потом) - и тогда сразу заводить геттеры и сеттеры. Если это один-два человека, как с Обероном и работают, то, пожалуй, что так. Особенно, если это вполне законченная замкнутая мини-система. Но я уже писал выше, что так далеко не всегда и такая модель не всегда пригодна, для больших команд, больших проектов. Да и ilovb тоже написал.
Представить себе, что сразу не было ясно, будет ли опосредование методами - или это просто поле, - такое представить трудно. |
Автор: | ilovb [ Воскресенье, 15 Январь, 2017 12:47 ] |
Заголовок сообщения: | Re: Массив |
qrkx писал(а): Вы все вроде умные люди, а в ветке форума про массивы срач устроили. "умные люди" - очень древние мифические существа. Как оборотни. От тупых отличить очень сложно. Предлагаю использовать другой ярлык: "честные люди". |
Автор: | Иван Денисов [ Воскресенье, 15 Январь, 2017 13:37 ] |
Заголовок сообщения: | Re: Массив |
qrkx писал(а): Вы все вроде умные люди, а в ветке форума про массивы срач устроили. Количество инфоповодов устроить интересную беседу крайне мало, поэтому используется любая зацепка |
Автор: | prospero78 [ Четверг, 19 Январь, 2017 10:30 ] |
Заголовок сообщения: | Re: Массив |
(1) "умные люди" -- легко отличаются от глупых. Умные люди гораздо реже делают лишние телодвижения, в отличии от глупых. (2) "честные люди" -- легко отличаются от нечестных. Честные люди легко признают ошибки. И быстренько их исправляют, в отличии от не честных)) Массивы, которые можно задать одной строкой при инициализации, возможно, нужны. Но я к "зашитым" данным отношусь с недоверием. Ресурсы должны быть отделены от алгоритмической части. Это и гибкость, и дополнительный контроль. В том числе и со средствами оптимизации. Проперти -- это как "Кому нравится поп, а кому попова дочь". Илья достаточно аргументированно объяснил: композиция предпочтительней наследования. и весь смысл проперти рассеивается, как с белых яблонь дым. Интерфейсам это не сильно помогает. Чтение у полей проще, и присваивание контролируемое -- точно такой же интерфейс, да ещё и явный. по сравнению с маскировкой в проперти. В дискуссии по одному очку получают, Ф.В., Илья. Иван. Борис -- минус полочка, Кемет (без обид) -- минус очко. |
Автор: | Info21 [ Четверг, 19 Январь, 2017 20:57 ] |
Заголовок сообщения: | Re: Массив |
Можно Вам три минуса? За 1), 2) и за капитализм )))) |
Автор: | prospero78 [ Понедельник, 23 Январь, 2017 11:01 ] |
Заголовок сообщения: | Re: Массив |
))) Провокация состоялась)) Умный и честный человек детектед)) Минусы в спокойной манере обсуждения принимаются)) |
Автор: | Валерий Лаптев [ Воскресенье, 04 Ноябрь, 2018 19:38 ] |
Заголовок сообщения: | Re: Массив |
Кстати, о ресурсах, которые должны быть отделены от алгоритмизации. Можно предложить такое решение. - пока пишется и отлаживается программа, гораздо проще и удобней объявлять переменные в том месте, где они нужны. - в релизном варианте компилятор отделяет (например, перенося объявление объектов в секцию объявлений). Буду пилить такое в рамках своих работ. |
Автор: | Иван Денисов [ Воскресенье, 04 Ноябрь, 2018 20:47 ] | ||
Заголовок сообщения: | Re: Массив | ||
Валерий Лаптев писал(а): Кстати, о ресурсах, которые должны быть отделены от алгоритмизации. Можно предложить такое решение. - пока пишется и отлаживается программа, гораздо проще и удобней объявлять переменные в том месте, где они нужны. - в релизном варианте компилятор отделяет (например, перенося объявление объектов в секцию объявлений). Буду пилить такое в рамках своих работ. Размышлял над этой проблемой и понял, что в Блэкбоксе предлагается очень интересное решение для объявления переменных. По F2 открывается новое отображение текста для одной и той же модели. Так что в одном окне всегда возможно держать верх модуля или процедуры и дополнять переменными по ходу написания "тела".
|
Автор: | Info21 [ Воскресенье, 04 Ноябрь, 2018 21:06 ] |
Заголовок сообщения: | Re: Массив |
Валерий Лаптев писал(а): - пока пишется и отлаживается программа, гораздо проще и удобней объявлять переменные в том месте, где они нужны. Это при неправильной базовой технике. При правильной не удобней и не отлаживается (в обычном смысле).
|
Автор: | Валерий Лаптев [ Воскресенье, 04 Ноябрь, 2018 22:39 ] |
Заголовок сообщения: | Re: Массив |
Info21 писал(а): Валерий Лаптев писал(а): - пока пишется и отлаживается программа, гораздо проще и удобней объявлять переменные в том месте, где они нужны. Это при неправильной базовой технике. При правильной не удобней и не отлаживается (в обычном смысле).Безапелляционное утверждение. 1. Базовая техника - правильная. От кодов минска-22 через фортран и паскаль, естественно... 2. Отлаживается еще как. И без отладчика. Я студентам давно уже внушаю, что вообще-то отладка - в голове, а не в отладчике... 3. Локальность переменной цикла - это хорошо, а не плохо. Локальность переменных в блоке if (например) - это лучше, чем, не локальность этих переменных в этом блоке. Иван предложил приемлемое решение для ББ. |
Автор: | Info21 [ Понедельник, 05 Ноябрь, 2018 11:56 ] |
Заголовок сообщения: | Re: Массив |
Валерий Лаптев писал(а): Иван предложил приемлемое решение для ББ. Вы сами опровергли своё утверждение о безапелляционности ))
|
Автор: | Kemet [ Понедельник, 05 Ноябрь, 2018 16:00 ] |
Заголовок сообщения: | Re: Массив |
Валерий Лаптев писал(а): Кстати, о ресурсах, которые должны быть отделены от алгоритмизации. Всё уже украдено до нас - в Модуле-3 можно писать так:Можно предложить такое решение. - пока пишется и отлаживается программа, гораздо проще и удобней объявлять переменные в том месте, где они нужны. - в релизном варианте компилятор отделяет (например, перенося объявление объектов в секцию объявлений). Буду пилить такое в рамках своих работ. Код: VAR .....; BEGIN ....... ....... VAR .....; BEGIN ..... END; END; То есть любая секция BEGIN END может иметь предшествующую секцию VAR. |
Автор: | Валерий Лаптев [ Понедельник, 05 Ноябрь, 2018 16:12 ] |
Заголовок сообщения: | Re: Массив |
Info21 писал(а): Валерий Лаптев писал(а): Иван предложил приемлемое решение для ББ. Вы сами опровергли своё утверждение о безапелляционности ))Мы по-разному оцениваем одни и те же высказывания... Тем не менее, я сделаю диалект с возможностью объявления переменных по месту. А там - посмотрим. |
Автор: | Валерий Лаптев [ Понедельник, 05 Ноябрь, 2018 16:14 ] |
Заголовок сообщения: | Re: Массив |
Kemet писал(а): Всё уже украдено до нас - в Модуле-3 можно писать так: ... То есть любая секция BEGIN END может иметь предшествующую секцию VAR. Ну, у нас не Модула-3, а ББ+КП. |
Страница 3 из 4 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |