Модификатор доступа для типа

Достаточно часто появляются ситуации, когда тип нужно скрыть внутри модуля или библиотеки, но сделать это через Interface/Implementation нет возможности, не говоря уже о том, что такая структура модуля устарела. Я предлагаю ввести модификаторы доступа для типов, как в Oxygene:

Type my = private class
End;
  • За введение модификаторов
  • Против введения модификаторов

0 голосов

1 лайк

Считаю полезным функционалом. С одной стороны - эта возможность перекроет надобность пользоваться interface и implementation в модулях, будет легче перейти на C# - там аналогичный функционал уже имеется. Это из плюсов. Но с другой, язык утратит еще одну свою уникальность. Но, давайте послушаем, что скажет сообщество.

Я, пожалуй, воздержусь голосовать. Ни разу не было нужно, но бесполезным тоже счесть не могу. Что-то из разряда “не в первую очередь”, если бы мое мнение что-то решало.

Ну, так тут мнение каждого что - то, да решает.

@Admin, честно говоря, я не наблюдаю множество активных участников на этом форуме. Может, стоит привлечь к голосованиям учащихся?

@Gleb, уточнение. Если класс абстрактен, то Вы предполагайте:

type
  TClass = public abstract class
  end;

?

Да, а что Вас смущает?

Боюсь, 90 % не сможет даже примерно дать описание класса.

Структура модуля не устарела. Помещайте такой класс внутрь implementation

Я же написал, что не всегда это возможно.

Вот Вам простой пример. Модуль содержит публичный класс, приватное поле которого - объект приватного класса. Сделать такое сейчас невозможно, хотя никаких противоречий нет.

Unit U1;
Type a = private class
End;
Type b = public class
  Private pole1: a;
End;
End.

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

Unit U1;
Type PByte = private ^Byte;
End.

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

Да, есть случаи. В основном первый пример что привёл @Gleb - то есть случаи когда надо чтоб второй класс имел переменные или принимающие/возвращающие параметры методов типа первого класса. При этом первый класс не должен передаваться тому кто подключит модуль. К примеру, если мы не хотим чтоб тот кто подключает модуль - делал инстансы этого типа.

Тайпклассы для меня - тёмный лес, но с первой проблемой я не раз сталкивался на практике. Один раз - в библиотеке цветовых пространств, второй раз - в закрытом пока что проекте ConvNetABC.

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

А это не экземпляром называется? Но дело не только в возможности использования. Зачем пользователю видеть то, что не нужно.

1 лайк

Да, это называется инкапсуляция, и это именно не то что тянут по глупости из C языков, это то что проверено опытом. Даже программисту который писал библиотеку - не стоит видеть то что не надо менять. И эти принципы действуют и в C++, то есть это не для неопытных, это правилось для всех.

*инкапсуляция

Я как бы и не против, а только за. :smile:

1 лайк

Ничего. Я просто уточнил.

Опрос пока что радует(не накаркать бы), но маловато людей оценило идею. Да и не понятно, кто.