Заставьте "частных" участников вести себя как "строго частный"

Question

Как насчет функции в следующей версии Delphi, позволяющей это сделать?

Возможно, это может быть переключение компилятора, повышающее все **private** с до **strict private** с.

... или это может быть особенностью нового не унаследованного компилятора font-end , о котором говорил Ник Ходжес. => private всегда ведет себя как strict private.

РЕДАКТИРОВАТЬ: Причина, по которой я этого хочу, заключается в том, что я просто не хочу добавлять тысячи strict s к моим private модификаторам. Кроме того, поведение "строго частного" является поведением по умолчанию на любом объектно-ориентированном языке, с которым я знаком!

Answer 1

Цитировать из статьи:

Итак, мы работаем над созданием «новой Delphi» и новой архитектуры компилятора, чтобы ваш существующий код работал, чтобы испускать 64-битные двоичные файлы с использованием Delphi и C ++ Builder, и, возможно, нескольких других двоичные файлы, пока мы на нем. И все это должно быть сделано правильно, чтобы все это работало на вас.

Я интерпретирую это так, как будто codegear изменит поведение private. Затем они предложат сохранить прежнее поведение, как в прошлом.

Просто для пояснения, в классе есть 6 различных уровней доступа (хорошо 7, но автоматизация устарела).

public: Anything that can access the object can access this.
protected: Methods in the class and its subclasses and anything in the same unit can access.
strict protected: Methods in the class and its subclasses can access.
private: Methods in the class and anything in the same unit can access.
strict private: Methods in the class.
published: As public buth with runtime information for the object inspector.

Answer 2

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

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

Причина, по которой private ведет себя так же, как и в случае с friend в C ++, - позволяет определенным классам (или процедурному коду) получить доступ к private членам. VCL и RTL интенсивно используют это поведение, поэтому переключение компилятора или полное изменение нарушит весь этот код.

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

Answer 3

Я ожидал, что причиной вашего желания изменить значение private было то, что вам нужно более строгое поведение без нарушения обратной совместимости. Я подумал, что вы создаете библиотеку, которую вы хотели бы использовать с Delphi 7 и более ранними версиями, в которой нет модификатора strict.

Но если это не ваша причина, тогда я не думаю, что вам есть над чем работать. Вы можете легко конвертировать весь свой код private в strict private с помощью простого скрипта.

perl -i.bak -pe 's/(?<!\bstrict )\b(private|protected)\b/strict $1/ig' *.pas

Требуется любой private или protected, который не является строгим, и перед ним ставится strict. Он изменяет файлы на месте. (Осторожно, он также может вставлять «строгий» в строковые литералы.)

Так или иначе, я не думаю, что мы увидим, что private станет строгим в ближайшее время. Это может привести к поломке старого кода, и в этом нет особой практической выгоды. Это позволяет пуристам иметь «более чистый» код, но они уже могут получить его, просто используя strict. Я думаю, что если мы когда-либо собирались иметь «строгую» видимость по умолчанию, то время для изменения было тогда, когда strict был введен в первую очередь. Но, как сегодня обстоят дела, у нас уже есть способ получить строгие спецификаторы видимости, поэтому нет необходимости в других изменениях.

Answer 4

Я не совсем понимаю вопрос. Но зачем вам эта функция? Почему бы просто не заменить Privates в вашем коде на Strict Privates, если вы этого хотите?