Перекрытие штатной функции ( процедуры )

← →
Андрей Сенченко © (2004-02-26 11:55) [0]

Если кто сталкивался - поделитесь опытом кто как с этим боролся.

Анекдотическая ситуация ( наверное в "Потрепаться", но все-же здесь )

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

Порылся в Фаронове, штатной функции не нашел.

Быстренько накропал свою - вроде в чем проблема то ?

Долго не мог понять - почему в том модуле, где она объявлена, она работает как часы, а в остальных модулях ( там где она видна через USES ) - нет.

Долго ржал, когда по Ctrl - левый клик мышью на имени процедуры ввалился в модуль Windows, где есть точно такая же функция, но с одним отличием -
моя ChangeFileExt ( а как ее еще было назвать ) требует во входном параметре только собственно новое расширение, а штатная ChangeFileExt - новое расширение с точкой. Соответственно во всех модулях, где Uses windows стояло раньше Uses мой_модуль_с_описанием, я получал в результате выполнения имя файла со сцепленным расширением.

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

Хотелось бы экспертной оценки Мастеров чтоли :)
После бессонной ночи и долгого мучительного ковыряния карандашом в ухе над поиском наиболее подходящего названия ВАШЕЙ функции проверяете ли Вы существование аналогов ? Или как-то иначе обходите ?

← →
Тимохов © (2004-02-26 12:01) [1]

если имя очень короткое пишу в начале имя модуля UnitName.ChangeFileExt.

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

type
tutil = class
public class procedure _ChangeFileExt(...);
end;

вызов где-то

begin
tutil._ChangeFileExt(...);
end;

не очень коротко, зато однозначно.

← →
ssk (2004-02-26 12:03) [2]

ну, способов несколько может быть:

1. пишешь ИмяКоманды( и ждешь подсказок
2. сам лезешь в помощь и пытаешься найти это имя
3. задаешь поиск придуманного имени в файлах *.pas в директории, куда ставил Дельфи

может еще что-то можно придумать, но на данный момент мысль остановилась :-)

← →
Anatoly Podgoretsky © (2004-02-26 12:10) [3]

Андрей Сенченко © (26.02.04 11:55)
Писатели компонентов рекомендуют следующий метод, использовать префикс со своими инициалами. Посмотри как например сделано у популярных или стандартных библиотек.

Тот же метод можно распространить и на рядовые процедуры, вместо ChangeFileExt писать ASChangeFileExt

Тогда степень риска уменьшается или как уже указали использовать каноническое обращение Модуль.Остальное тогда коллизии полностью отсутствуют.

← →
Гаврила (2004-02-26 12:36) [4]

>>Anatoly Podgoretsky © (26.02.04 12:10) [3]
Зато читабельность кода резко снижается.
Кроме того, и среди штатных имен бывают такие наклдадки
например Windows.TBitmap и Graphics.TBitmap.
Хорошо, что в данном случае компилятор не пропустит, если произошла накладка.
Я думаю, просто аккуратность должна быть. При обнаружении штатной функции, совпадающей с моей, тут же сношу свою нафиг :-)

← →
Anatoly Podgoretsky © (2004-02-26 12:40) [5]

Гаврила (26.02.04 12:36) [4]
А вот тут трудно стобой согласиться, читабельность снижается как раз при не применении канонической формы, поскольку нельзя понять а что же на самом деле вызывается, тем более что часто проблему решают путем смены порядка в USES

← →
Sandman25+1 (2004-02-26 12:42) [6]

В случае совпадения пишу имя модуля.
Никакие префиксы и постфиксы не гарантируют уникальности на 100%.

← →
Гаврила (2004-02-26 12:55) [7]

>>Anatoly Podgoretsky © (26.02.04 12:40) [5]
я не про каноническую форму, я про префиксы :-)

← →
Anatoly Podgoretsky © (2004-02-26 13:19) [8]

Естественно, частичное решение, правда попутно видна и принадлеэность, а гарантия только в каноническом

Когда Дельфи только развивалась, это проблема встала очень остро, много компонент было с одинаковыми именами, плюс Борланд подлил масла в огонь. После этого пришли к негласному соглашению, компоненты без префиксов дляя Борланда, остальные с префиксами. Количество коллизий сразу снизилось.

← →
Тимохов © (2004-02-26 13:26) [9]

Префиксы это нормально.
Я уже давно пользуюсь методами класса (class function), т.е. как написал в [1]. При этом для классов задаю префиксы по имени своего проекта.

Например TGaasDb, а в нем
class procedure _Connetion(...);
class procedure _Disconnetion(...);
class procedure _Fetch(...);
class procedure _Execute(...);
и т.д.

Или TGaasRBTree (красно-черное дерево), а в нем
class procedure _Add(var aTree: Pointer; const aValue: Variant)
class function _Find(const aTree: Pointer; const aValue: Variant): Integer;
и т.д.

Т.е. префиксы у меня есть на верхнем уровне (т.е. на уровне класса), а на уровне методов префиксов нет.

Сам долго шел к такой организации. Дозрел год назад. Постепенно по необходимости перевел все на такой подход. Считаю, что при определенном знании читающего о подходе обзорность просто замечательная.

← →
Anatoly Podgoretsky © (2004-02-26 13:29) [10]

Тимохов © (26.02.04 13:26) [9]
На уровне методов префиксы и не требуются, поскольку они оназначно идентифицируются классом и как правило доступ через объект. Применять же сдесь префиксы это просто снижать читабельность, но в твоем случае у тебя как раз применены префиксы в виде подчеркивания

← →
Тимохов © (2004-02-26 13:31) [11]

> Anatoly Podgoretsky © (26.02.04 13:29) [10]

Подчеркиваниями я просто обозначаю методы классов (class procedure).

← →
Гаврила (2004-02-26 13:36) [12]

>>Тимохов © (26.02.04 13:31) [11]
Подчеркиваниями обычно обозначаются методы для внутреннего пользования ("не вызывай меня снаружи руками") :-)

Насчет префиксов для библиотек компонентов, которые идут на продажу, я соглашусь(например Rx). Но в свои методы, которые используются только самолично, добавлять префиксы - это имхо, перебор.
То есть все, что пишет программист, начинается с префикса. Это геморрой. И писать, и читать

← →
Тимохов © (2004-02-26 13:38) [13]

> Гаврила (26.02.04 13:36) [12]
> >>Тимохов © (26.02.04 13:31) [11]
> Подчеркиваниями обычно обозначаются методы для внутреннего
> пользования ("не вызывай меня снаружи руками") :-)

У меня таких нет. Т.к. у меня нет свободных процедур (все методы), то если его не нужно вызывать руками, то пишу

private class procedure _fDotTakeMe();

← →
Sandman25+1 (2004-02-26 15:29) [14]

Тимохов

Я стараюсь не плодить сущности без надобности. Если нужна процедура или функция, не относящаяся к какому-либо классу, я ее не буду делать методом. И понятнее, и быстрее работает. Единственная проблема с коллизиями, но раз уж все равно вызывается в виде myclass.mymethod, то лучше вызывать myunit.myproc. Тем более, что иначе есть шанс нарваться на то, что уже где-то есть класс myclass, и тогда придется писать еще длиннее: myunit.myclass.mymethod.

← →
Тимохов © (2004-02-26 15:43) [15]

> Тем более, что иначе есть шанс нарваться на то, что уже
> где-то есть класс myclass, и тогда придется писать еще длиннее:
> myunit.myclass.mymethod.

Для этого я у класса всегда делаю префикс.

> . И понятнее, и быстрее работает

Имхо это сильно мало значимо. Различается одним mov.

← →
Sandman25+1 (2004-02-26 15:49) [16]

>Для этого я у класса всегда делаю префикс.

Если есть префикс, гарантирующий уникальность, то почему бы не дать его процедуре? :)

>Имхо это сильно мало значимо. Различается одним mov.

А если в цикле от 1 до 10 в N степени? Добавление элементов, например.

← →
К.К.С. (2004-02-26 16:02) [17]

встречный вопрос, а зачем эта процедура если можно заменить одноимённой стандартной;)

← →
WebErr © (2004-02-26 16:06) [18]

Короче так, сиди дальше, ковыряй карандашом в ухе, и найди обыкновенное (БЕЗ ВСЯКИХ ПРЕФИКСОВ!) название своей процедуре. Я тоже использую префиксы, но внутри классов - те переменные, которые внешние юниты не будут видеть! Но префикс перед проседурой, которую потом будешь юзать - это "мда! ... ". Мой совет - назови её по своему, пусть даже придёться проковырять карандашом дыру в ухе. У меня порой (и оч. часто) возникают похожие ситуации, и пока справляюсь (пришлось даже одну функцию LogicInit назвать). Программеру без смекалки нельзя! Удачи! :))))

← →
Sandman25+1 (2004-02-26 16:09) [19]

[18] WebErr © (26.02.04 16:06)

Называть нужно так, чтобы было понятно. Причем желательно не только себе.

← →
Тимохов © (2004-02-26 16:26) [20]

> А если в цикле от 1 до 10 в N степени? Добавление элементов,
> например.
Там и подход другой.
Скроее придется делать эмуляцию сишных inline функций, т.е. код процедуры засовывать по месту.

Т.е. имхо в зависимости от задачи и подходы разные. Оптимизация, знаете ли вещь творческая. К радости она не так часто нужна.

← →
Sandman25+1 (2004-02-26 16:31) [21]

[20] Тимохов © (26.02.04 16:26)

При добавлении элементов из 10 мест (да еще если и в разных модулях, да еще у разных разработчиков) копируется 10 раз текст метода добавления?

Наверное, Java был первым изученным языком?

← →
Sandman25+1 (2004-02-26 16:33) [22]

Тимохов

Не обижайся, что я так строго. Просто мне интересно, ты постоянно упрекаешь мастеров, что они не признают свои ошибки/неоптимальности, постоянно выкручиваются...

← →
Тимохов © (2004-02-26 16:34) [23]

> Sandman25+1 (26.02.04 16:31) [21]

Не надо приколов.
У меня история большая и стандартная, думаю, для многих.

Мой метод:
1. Оптимизировать надо то, что надо, т.е. что даст значительный прирост. Делать это надо по возможности меньше. И с большим вниманием и ответственностью.
2. Все остальное надо делать как считаешь методологически верно.

← →
Тимохов © (2004-02-26 16:37) [24]

> . Просто мне интересно, ты постоянно упрекаешь мастеров,
> что они не признают свои ошибки/неоптимальности, постоянно
> выкручиваются...

Мастеров? Да? А я не замечал, просто подчеркиваю ошибки, а чьи они - мне все равно. Просто так получается, что мастера знают, что говорят, а не у мастеров и ошибок то нет - т.к. часто и кода нет, хотят на халяву.

Почему мы еще тут - пора на 9 пунктов правее.

← →
Sandman25+1 (2004-02-26 16:38) [25]

> Sandman25+1 (26.02.04 16:38) [25]

Вы выдрали фразу из контекста. Прочтите еще раз.

SysUtils.ChangeFileExt()
и всё.

← →
Sandman25+1 (2004-02-26 16:49) [28]

Мы все еще обсуждаем subj, почему мы должны быть в потрепаться.

Прочел еще раз.
1. Все, что не надо оптимизировать, делаете методом.
2. Делаете только то, что считаете методологически верным.
3. Значит, считаете методологически верным делать методом все, что некритично к оптимизации.
Вопросов больше не имею.

← →
Serginio666 (2004-02-26 18:01) [29]

Интересно, что в Delphi 8 все функции и переменные видны в MSIL как статические функции и переменные класса unit в этом намеспейсе. И обычное применение Unit.MetodName обычная безконфликтная практика.

>> К.К.С. (26.02.04 16:02) [17]
>> WebErr © (26.02.04 16:06) [18]
>> Fay © (26.02.04 16:42) [27]

Еще раз. Видимо в процессе чтения ветки суть основного вопроса была Вами утеряна. Она такова :

1. Есть необходимость совершить некие действия.
2. Я ( Вы, Он, Она, ... ) априори не знаем о существовании штатной функции для осуществления этих действий. Причина незнания не важна. Важен сам факт.
3. Я ( Вы, Он, Она, ... ) пишем собственную функцию или процедуру для осуществления этих действий. При этом выбираем для нее имя ( естественно исходя из нашего знания английского и навыка в обозначении элементов программного языка ) аналогичное имени уже существующей штатной функции.
4. В случае несложной по своим оперативным возможностям процедуры ( функции ) семантика нашей функции ( имя, количество и тип параметров, возвращаемый результат ) оказываются полностью аналогичными соответствующим параметрам штатной функции.
5. При этом наша собственная и штатная функции отличаются набором производимых действий ( черный ящик ), в следствии чего поведение этой функции в разных сегметах программы становится непредсказуемым.

Типовой пример был приведен на основе функции ChangeFileExt()

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

Как автор ветки предлагаю перекинуть в "потрепаться"

> как с этим справлялись те, кто сталкивался с аналогичными
> ситуациями.

Я не сталкивался, а потому и не справлялся. Поскольку достаточно нажать F1 - и сразу становится ясно, нужно ли писать свою функцию или есть готовая. И достаточно сделать Find in files - и сразу становится ясно, не перекрыл ли я уже существующее имя.

Для своих функций (не методов) избрал постфикс и проблем не имею.
Если есть необходимость, то добавляется имя модуля.
function Before_(const Search, Find: string): string;
function After_(const Source, Find: string): string;
function AfterToEnd_(const Source, Find, Ends: string): string;
function WordCount_(S: string; Delims: CharSet): word;
и тп

to Serginio666:
>Интересно, что в Delphi 8 все функции и переменные видны в MSIL
>как статические функции и переменные класса unit в этом
>намеспейсе.
Объяснение тому простое. MSIL чисто объектный, поэтому приходится таким образом эмулировать переменные/процедуры уровня модуля.

to Андрей Сенченко:
>Вопрос был - как с этим справлялись те, кто сталкивался с
>аналогичными ситуациями.
Стоит стараться не создавать таких ситуаций. Ну а если уж случилось, то отладчик в руки и вперед.

Андрей Сенченко © (26.02.04 21:09) [30]
Не стоит, вполне нормальное обсуждение и по теме конференции.
А что выше приведенные советы, что ни будь дали или нет?

Юрий Зотов © (26.02.04 21:44) [31]
Проблема может возникнуть и потом, правда вот тогда надо это обнаружить и исправить.

>Андрей Сенченко © (26.02.04 11:55)
>...и долгого мучительного ковыряния карандашом в ухе...

Эй ! Поаккуратнее там с карандашиком. Барабанная перепонка не железная ! В мире достаточно глухих...
:)

Перекрытие штатной функции ( процедуры ) Найти похожие ветки