Извините, ничего не найдено.

Taugeshtu · 12.04.2016, 13:20

Задался тут вопросом, а насколько вообще ценны в дизайне ЯП модификаторы уровня доступности?
Полезность public/private разделения я явственно ощущаю. А вот дальше начинаются "а что если"...

Была ли у вас реальная производственная необходимость использовать internal, и есть ли у вас серьёзные аргументы против идеи убрать private, оставив protected?

Рассуждения исключительно умозрительные, про "мой проект сломается" не упоминать - считаем, что делаем новый высокоуровневый ЯП.

Andvrok · 12.04.2016, 14:06

Сообщение от Taugeshtu

Была ли у вас реальная производственная необходимость использовать internal

Да.

Сообщение от Taugeshtu

есть ли у вас серьёзные аргументы против идеи убрать private, оставив protected?

Нет, приват и протектед стоит разделять.

Taugeshtu · 12.04.2016, 14:17

Нуууу, так не интересно, а аргументы где?

pax · 12.04.2016, 15:05

Все private и internal методы/поля/свойства/классы мы обфусцируем.

protected при наследовании часто использую, их никому не видно, кроме наследников.

internal на уровне dll видно, если проектируешь dll для кого-то, то делаешь интерналами все что не надо видеть всем кто "снаружи", но надо иметь доступ отовсюду в самой dll.

C точки зрения Unity - internal не сериализуется, хоть и видна всем. Не надо дополнительного атрибута NonSerialized для публичных полей.

Опять же с точки зрения Unity для методов событий типа Update использую protected чаще чем private потому, что тогда решарпер их не подкрашивает, что это метод не используется нигде.

KCEPOKC · 12.04.2016, 16:54

protected очень даже нужен, когда надо работать с наследованием. Его отсутствие бы сильно усложнило (точнее, прокопипастило), вроде как, элементарный код.
Насчет internal уже не знаю, что сказать, но pax имхо довольно четко проаргументировал "за".
Где-то в собственных сырцах есть хороший пример для protected (на PascalABC.Net), только хз, где он.
p.s. да, я каннибал, а еще я люблю баловаться с инвалидами.

pax · 12.04.2016, 17:01

Сообщение от pax

internal на уровне dll видно, если проектируешь dll для кого-то, то делаешь интерналами все что не надо видеть всем кто "снаружи", но надо иметь доступ отовсюду в самой dll.

Прокомментирую сам себя еще, опять с точки зрения Unity. Пример: пишешь плагин, ложишь его в папку Plugins. Используешь internal по своему усмотрению. В обычных скриптах, которые не в Plugins, а в самом проекте, этих internal'ов не видно. Никто не получит доступ к неконтролируемому полю, если специально не зайдет и не отредактирует исходники плагина. Почему интерналы в плагинах не видно и так понятно - отдельная dll, компилирующаяся до остального кода.

Taugeshtu · 12.04.2016, 17:02

Гм. В моей голове это всё звучало как-то стройнее... Попробуем ещё раз:
Если вам предложат писать на языке, в котором есть только public и protected, вас вырвет, или даже понравится? Ну так, чисто гипотетически.

pax · 12.04.2016, 17:17

Сообщение от Taugeshtu

Гм. В моей голове это всё звучало как-то стройнее... Попробуем ещё раз:
Если вам предложат писать на языке, в котором есть только public и protected, вас вырвет, или даже понравится? Ну так, чисто гипотетически.

Ну имхо это уже проблема языка и того, кто предложил, а не программиста, которому задачу решать надо. И ограничение это совсем другое, это не то, когда есть на выбор что использовать. Опять же, когда есть выбор, то все зависит от поставленных задач. Что было бы, если бы все приватные переменные классов Net Framework стали бы protected? Даже те, которые связаны с неконтролируемыми ресурсами. Все бы наследовались от этих классов и ломали бы все что можно.

Mr_F_ · 12.04.2016, 18:40

я всё (почти) делаю public, и мне ок.

RegIon · 12.04.2016, 19:40

Сообщение от Mr_F_

я всё (почти) делаю public, и мне ок.

Солидарен, если это конечно не отдельная dll. Правда и тут бывают неудобства.
Вчера пытался положить отдельную текстуру на глаз(смотри тему c# + OpenGL) (тз изменили, приспичило несколько видов радужки), так оказалось что только на процедурных моделях можно это делать, а на загруженных нет. Капец это было проблемно, так как поле SubMeshes было protected readonly. Узнал я это только после того, как написал issues автору библиотеки, ибо в исходниках сложно было найти не зная что искать. Быстро ответил и изменил protected на public, через 6-8 часов.

Randomize · 12.04.2016, 19:51

Сообщение от Taugeshtu

Если вам предложат писать на языке, в котором есть только public и protected, вас вырвет, или даже понравится? Ну так, чисто гипотетически.

А такое встречается довольно часто. Всё хорошо пока работаешь один.
Мне кажется эти искусственные ограничения как раз придуманы для ситуаций когда кода один кодер завещет другому код и как-бы объясняет:
Вот это наследуй и перегружай (protected)
А вот эту фигню лучше не трогать (private)

Но это всё усложняет. Заведомо предугадать как будут перегружать твои классы и всё при этом учесть очень не простая задача.

pax · 12.04.2016, 20:38

Сообщение от Mr_F_

я всё (почти) делаю public, и мне ок.

И работаешь наверное с проектом один?)

Ну и Рандом правильно говорит, все эти филосовские мысли только когда один сидишь прогаешь, пусть будет все пабликом, чего от себя самого скрывать все. Все меняется, когда работаешь в команде. В команде и правила написания кода применяются и правила комитов и комментариев. Топикстартер вероятно от того же программирования проектов в одиночку начал придумывать для себя, зачем мне эти ненужные модификаторы нужны то.

Mr_F_ · 12.04.2016, 20:39

И работаешь наверное с проектом один?)

да

pax · 12.04.2016, 20:41

Сообщение от Mr_F_

да

Ну коммент я выше дописал.

pax · 12.04.2016, 20:50

Сообщение от RegIon

Солидарен, если это конечно не отдельная dll. Правда и тут бывают неудобства.
Вчера пытался положить отдельную текстуру на глаз(смотри тему c# + OpenGL) (тз изменили, приспичило несколько видов радужки), так оказалось что только на процедурных моделях можно это делать, а на загруженных нет. Капец это было проблемно, так как поле SubMeshes было protected readonly. Узнал я это только после того, как написал issues автору библиотеки, ибо в исходниках сложно было найти не зная что искать. Быстро ответил и изменил protected на public, через 6-8 часов.

Приведу пару примеров:

1. Все открыто, ты меняешь какую-то одну переменную открытую, проблем особо не замечаешь. Потом работаешь дальше, начинают какие-то странные проблемы появляться. С чем это связано? А вот автор той dll не подразумевал, что кто-то будет менять эти переменные, это его "магические числа" что только с ними все работает. И в результате тратишь ппц сколько времени, на то чтобы разобраться.

2. Второй огромный минус когда все открыто - ты подключаешь библиотеку и на тебя сваливается гора ненужных методов и переменных, которые вообще не нужны тебе и всем остальным. Только автору самой библиотеки. И ты должен тратить уйму времени, чтобы отсеять для себя только то, что именно тебе необходимо. Которое выполняет функционал, для которого библиотека предназначена.