Ответ на »сообщение 3784« (Сергей Перовский)
___________________________

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

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

Ответ на »сообщение 3761« (SAGE)
___________________________

Ответ на »сообщение 3748« (Geniepro)

Действительно, если убрать wallpaper такой эффект пропадает...
Я думал дело не воллпейпере... Старался не кликать по столу :)
Но эффект похоже не повторяется если поставить потом другой wallpaper.

Насколько реальное приложение? - http://sage.h15.ru/?e1l1
Там же по поводу кириллических кодировок для Blebottle - http://sage.h15.ru/?e1l2

Рабочий стол масштабируется к размерам обоев :). У меня такой проблемы не возникает - ЖК монитор с разрешением 1280х1024 (видать как и у швейцарцев). :)

Ответ на »сообщение 3783« (Руслан Богатырев)
___________________________
>>>Проблема спецификации процедуры. Не были зафиксированы предусловия (включая ограничения на контекст использования).
Спасибо, это я знаю :)
Я привел простейший пример. В большинстве случаев предусловия (и тем более контекст) гораздо сложнее. Фокус в том, что поместив замену в цикл автор в чистом виде расширил область применения, во всяком случае был в этом уверен. То, что он при этом сузил контекст использования осталось незамеченным (неосознанным).
А зависимость такая есть: расширение области применения ведет к усложнению контекста. Поэтому я очень боюсь "доработок" в сторонних компанентах - они требуют полномасштабного тестирования всей системы. Мне хватает необходимости тестирования под разными версиями Windows с разными настройками, чтобы множить это количество вариантов на количество версий стороннего компанента.
Кстати, в моей задаче вариант с множественным вхождением параметра не встречался - замена на "более продвинутый" модуль была сделана под давлением рекламы. Я мог не править новый модуль, а просто вернуться к старому.
Что будет происходить, если новые версии модулей будут приходить и включаться в работу автоматически мне представить страшно.

Ответ на »сообщение 3782« (Сергей Перовский)
___________________________

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

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

Ответ на »сообщение 3768« (AVC)
___________________________
>>>Возможно, строку надо было заменить саму на себя?
Конечно :)
Но я не мог тестировать на совпадение - не знал, как называется параметр "в оригинале". А разработчику не пришло в голову как раз в силу работы на уровне текста запроса - он видимо представлял себе, что пользователь будет в курсе, что на что заменяется и не будет вызывать процедуру, если запрос уже правильный.

Ответ на »сообщение 3780« (Руслан Богатырев)
___________________________

Еще о концептуальной экономии применительно к классическому Оберону. Напомню, что в прошлом году в ходе переписки с Виртом и уточнения его взглядов на Оберон с позиций нынешних представлений (16 лет спустя), удалось выяснить, что он считает Оберон образца 1990 г. хорошо сбалансированным языком. Единственными правками, с его точки зрения, могло бы быть:
1. Read-only экспорт переменных по умолчанию и read-write как опция (но здесь у него сомнения)
2. Отказ от излишних базовых типов, различающихся диапазоном представления (SHORTINT=LONGINT=INTEGER). Это стабилизирует язык во времени, вынося вопросы конкретизирующего программирования на иной уровень.
3. Возврат оператора FOR.

По первому пункту стоит заметить, что из четырех базовых сущностей, размещаемых внутри модуля и допустимых к экспорту, -- типа, процедуры, константы и переменной -- только переменная может допускать трактовку двух видов экспорта -- на чтение и на чтение-запись. Это вводит определенную путаницу: в Обероне нет экспорта на чтение, есть только на чтение-запись (модификатор -- звездочка), в Обероне-2 и КП есть тот и другой (модификатор -- минус). Замечу, что экспорт переменных на чтение был еще в экспериментальной Модуле (не Модуле-2). Если фантазировать, то видимо вполне можно было бы обойтись переменными с экспортом только на чтение, а модификацию ставить под контроль соответствующих процедур. Хотя это весьма спорно.

Второй пункт довольно жесткий, но делать язык (даже системного программирования) заложником архитектурных чихов -- тоже не совсем правильно (int16, int32, int64, int128, int256 и т.д. и т.п.). Отсюда можно сделать вывод, что в отношении поддержки двух разных типов CHAR применительно к КП даже в поисках компромисса видимо следует исходить из одного базового типа. Но это моя излишне вольная трактовка. Во всем должно быть чувство меры (как в добавлении средств, так и в их изъятии).

Ответ на »сообщение 3777« (Руслан Богатырев)
___________________________

Кроме того, в отношении способа передачи он остановился на двух -- передача по значению (by value, by copy) и передача по ссылке (by reference), проведя аналогию с константами и переменными (напомню, что в классическом Паскале 1970 г. указывалось именно так -- const или var).

Решив упростить изложение проблемы, я по ходу внес некоторую путаницу.

Дело в том, что на самом деле при передаче параметра (фактический-формальный) надо различать:
1. способ передачи (по ссылке, по значению, по имени)
2. режим передачи (оригинал, копия)
3. характер передачи (входной, выходной, входной-выходной)

Совмещение 1 и 2 вызывает путаницу (особенно когда речь идет о VALUE-out и VALUE-inout, где под VALUE понимается копия, т.е. режим передачи).

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

Проблема возникает и из-за того, что было бы неплохо различать константы-значения (RC -- т.е. только чтение и значение никогда не меняется) и разные виды переменных -- R (read-only), W (write-only) и RW (read-write). Как только мы не делаем различий между оригиналом и переменной (называя "по ссылке" и подразумевая, что это параметр-переменная), неизбежно возникает путаница. Под первыми (R) понимаются переменные, допускающие только режим чтения (это не трактовка их как констант, они могут менять значения, доступные внутри данной процедуры, но она сама не может), под вторыми (W) -- только режим однократного присваивания (undefined, либо конкретное значение навечно), под третьими (RW) -- традиционные (привычные нам) изменяемые переменные.

Как только среди переменных мы начинаем проводить различия, выясняется, что оригинал (reference) и копия (copy) требуются для параметров-переменных, тогда как для параметров-значений разницы между копией и оригиналом практически нет (за вычетом накладных расходов на возможное создание копии). Использование оригинала или копии диктуется обычно вопросами эффективности (лучше передавать меньшие объемы) и безопасности (лучше отделять оригинал от вспомогательных вычислений до самого последнего момента -- неявного присваивания после завершения процедуры/функции).

На практике подход, принятый в КП, -- достаточно разумный компромисс во множестве вариаций триады "способ-режим-характер" передачи параметров. Минималистский подход Оберона -- концептуальная экономия, которая проистекает из желания Вирта минимизировать любую конкретизацию на уровне языка. Такой конкретизации, которая может быть вынесена на иной уровень (прагм компилятора, настроек проекта/среды и т.п.).

Ответ на »сообщение 3778« (Илья Ермаков)
___________________________

Написать что ли? :-)

Не надо. :) Лучше сначала разобраться и до конца понять цену вопроса.

Ответ на »сообщение 3777« (Руслан Богатырев)
___________________________

Вариантов и подходов может быть много, например, в классическом Обероне (где только два вида и запутаться в них трудно) префиксировать имя параметра специальным знаком (!), значения префиксировать не надо -- они и передаются по значению. Это может рассматриваться как расширение компилятора, однако, при этом формально нарушается описание языка (хотя такая мелочь элементарно приводится к формально-допустимому виду простой конвертацией).  В КП с этим сложнее, но например, в качестве маркировки могут быть ! (VAR), ? (OUT) и @(IN).

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

Вопрос относительно способа (по ссылке, по значению, по имени) и характера/режима (in, out, inout) передачи параметров натолкнул вот на какие размышления.

Никлаус Вирт в своих языках (Паскаль, Модула-2, Оберон) отказался от указания характера передачи. Кроме того, в отношении способа передачи он остановился на двух -- передача по значению (by value, by copy) и передача по ссылке (by reference), проведя аналогию с константами и переменными (напомню, что в классическом Паскале 1970 г. указывалось именно так -- const или var). Передача по имени ("текстуальная подстановка") была отвергнута.

Если открыть одну из его последних работ (Good Ideas, through the Looking Glass, 2006), то можно найти раздел "Передача параметров по имени в языке Algol", посвященный обоснованию отказа от передачи по имени (который был в Алголе-60). См. http://www.citforum.ru/programming/digest/wirth/

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

Мы могли бы просто удалить из языка параметры, передаваемые по имени. Однако эта мера была бы слишком решительной и поэтому является неприемлемой. Например, это препятствовало бы присваиванию параметрам для возврата результатов вызвавшей процедуре. Однако это соображение привело к замене в более поздних языках Algol W, Pascal и Ada средства передачи параметров по имени на средство передачи параметров по ссылке. Сегодня идея звучит следующим образом: относитесь скептически к чрезмерно сложным средствам и возможностям. В самом крайнем случае их стоимость должна быть известна пользователям до выпуска, публикации и распространения языка. Эта стоимость должна быть соразмерна преимуществам, получаемым при включении в язык данного средства.

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

Если через VAR обозначить передачу по ссылке, а через VALUE -- по значению, то теоретически возможны 6 вариантов: VAR-in, VALUE-in, VAR-out, VALUE-out, VAR-inout, VALUE-inout.

При этом если с VAR (оригиналом) понятно (что inout для него -- штатный режим, а in и out есть просто средства ограничения), то для VALUE возникают вопросы относительно out и inout; тогда как in -- штатный режим). Если при вызове процедуры и связывании фактических и формальных параметров обеспечивается постфактумное (по завершению работы процедуры) копирование значения формальных параметров в фактические, то VALUE-out и VALUE-inout теоретически имеют смысл. При этом параметр VALUE-inout инициализируется значением фактического параметра (до начала исполнения процедуры/функции). Другое дело, зачем нужны VALUE-out и VALUE-inout. Если в ходе выполнения процедуры произойдет сбой (исключение), то работа с копиями (VALUE) вместо оригиналов (VAR) предпочтительнее, поскольку откат к исходным значениям (до вызова) прост и понятен.

Язык Ada, где эту схему решили развернуть во всей красе, предпочел скрыть способ передачи (то есть сделать неявным физический смысл -- оригинал или копия), в результате это вылилось в тот текст пояснений-трактовок (достаточно замысловатый, если не сказать -- запутанный), который я привел ранее из предварительного описания языка (1979) и стандарта Ada-95.

Т.е. программисту нужно помнить, какие типы параметров относятся к by-copy type, а какие -- к by-reference type. После этого надо хорошо разбираться в правилах связывания фактических и формальных параметров. Если говорить о четкости (и надежности), то в идеале нужно иметь все 6 вариантов комбинаций.

На практике, однако, разработчики языков идут по пути компромисса. У Вирта (сторонника концептуальной экономии) оставлено прямое соответствие -- константа или переменная. Т.е. это прямое противопоставление подходу Ады: у Вирта уже способ передачи явный, а характер -- неявный. В результате из игры заведомо исключаются VALUE-out, VALUE-inout и VAR-in, а также нет различия между VAR-out и VAR-inout. Остаются в итоге VAR-inout (параметр-ссылка) и VALUE-in (параметр-значение). Причем, следует иметь в виду, что Оберон проектировался спустя почти 10 лет после появления в драфтах первых вариантов Ады, т.е. выбор Вирта в Обероне был более чем осознанным.

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

Авторы Компонентного Паскаля (Пфистер и др.), как я понимаю, решили скрестить Вирта с Адой. В результате в КП пополнили схему Вирта явным указанием (для передачи параметров-переменных) еще и характера передачи (IN, OUT), где IN допустим только для массивов/записей. Таким образом, расширили число возможных комбинаций: VALUE-in  -- для передачи параметров-значений и VAR-inout (VAR), VAR-in (IN), VAR-out (OUT) -- для параметров-переменных. Для КП выбор служебного слова "VAR" (вместо INOUT) диктовался, по-видимому, вопросами совместимости с Oberon-2 (Oberon), хотя, на мой взгляд, логичнее было бы использовать для параметров-переменных именно тройку INOUT, IN и OUT.

Что касается маркировки характера (в меньшей степени -- способа) передачи фактических параметров в точке вызова, то она безусловно повышает наглядность (т.е. полезна для анализа исходных текстов, особенно при их отчуждении). Вариантов и подходов может быть много, например, в классическом Обероне (где только два вида и запутаться в них трудно) префиксировать имя параметра специальным знаком (!), значения префиксировать не надо -- они и передаются по значению. Это может рассматриваться как расширение компилятора, однако, при этом формально нарушается описание языка (хотя такая мелочь элементарно приводится к формально-допустимому виду простой конвертацией).  В КП с этим сложнее, но например, в качестве маркировки могут быть ! (VAR), ? (OUT) и @(IN).