Всем привет.

В одной из дискуссий с этого форума была высказана мысль, что private-поля для структур по умоланию неудобны.

Откровенно говоря не вижу разницы между структурами и классами. На мой взгляд изменяемые поля нужно прятать от народа и делать их по умолчанию водимыми — это зло (провокация нарушения инкапсуляции).

Однако для неизменяемых полей и для свойств — это не так. Неизменяемые поля и свойства в 99% случаях объявляются для описания публичного интерфейса.

Может быть было бы разумно изменить для них умолчания и делать их по умолчанию public?

Здравствуйте, VladD2, Вы писали:

VD>Всем привет.

VD>В одной из дискуссий с этого форума была высказана мысль, что private-поля для структур по умоланию неудобны.
В С++ члены структур по умолчанию публичные а классов -- приватные(или защищенные, не помню)
VD>На мой взгляд изменяемые поля нужно прятать от народа и делать их по умолчанию водимыми — это зло (провокация нарушения инкапсуляции).
не поленились написать mutable -- не поленятся и писать public
VD>Однако для неизменяемых полей и для свойств — это не так. Неизменяемые поля и свойства в 99% случаях объявляются для описания публичного интерфейса.
По идеи поведение должно быть предсказуемо и однородно для любых членов.
Хотя, действительно get-only свойства в основном публичные
ПС. я так понял тут не только про стракты?
VD>Может быть было бы разумно изменить для них умолчания и делать их по умолчанию public?
Не поздно ли менять такое глобальное поведение?

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

Здравствуйте, BogdanMart, Вы писали:

BM>не поленились написать mutable -- не поленятся и писать public
+1
Для мьютабл-данных это не обсуждается даже. Я бы вообще запретил их публичными делать, была бы моя воля .

VD>>Однако для неизменяемых полей и для свойств — это не так. Неизменяемые поля и свойства в 99% случаях объявляются для описания публичного интерфейса.
BM>По идеи поведение должно быть предсказуемо и однородно для любых членов.
BM>Хотя, действительно get-only свойства в основном публичные

Да и обычные свойства тоже в большинстве своем публичные. Разве что ли set-ер может быть скрыт, но это уже внутри свойства. И с этим проблем нет.

BM>ПС. я так понял тут не только про стракты?

Ну, а что их отделять то? За одно логичнее будет поведение в вариантах. А то что-то везде по умолчанию привает, а в вариантха вдруг паблик.

VD>>Может быть было бы разумно изменить для них умолчания и делать их по умолчанию public?
BM>Не поздно ли менять такое глобальное поведение?

Я прикинул. Для большинства таких свойств и полей значения модификаторов доступа заданы явно. Так что к серьезным проблемам это не должно привести.

Можно пойти на такое решение только для свойств. Их то уж точно очень редко приватными делают. А протектед прописывается в явном виде. Так что вообще проблем не будет.

ЗЫ

В общем, это как идея. Я не настаиваю. Просто правильные соглашения могли бы сократить код не причиняя вреда. Одна проблема — усложнит ли это понимания.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, BogdanMart, Вы писали:

BM>>не поленились написать mutable -- не поленятся и писать public
VD>+1
VD>Для мьютабл-данных это не обсуждается даже. Я бы вообще запретил их публичными делать, была бы моя воля .

VD>>>Однако для неизменяемых полей и для свойств — это не так. Неизменяемые поля и свойства в 99% случаях объявляются для описания публичного интерфейса.
BM>>По идеи поведение должно быть предсказуемо и однородно для любых членов.
BM>>Хотя, действительно get-only свойства в основном публичные

VD>Да и обычные свойства тоже в большинстве своем публичные. Разве что ли set-ер может быть скрыт, но это уже внутри свойства. И с этим проблем нет.

BM>>ПС. я так понял тут не только про стракты?

VD>Ну, а что их отделять то? За одно логичнее будет поведение в вариантах. А то что-то везде по умолчанию привает, а в вариантха вдруг паблик.

VD>>>Может быть было бы разумно изменить для них умолчания и делать их по умолчанию public?
BM>>Не поздно ли менять такое глобальное поведение?

VD>Я прикинул. Для большинства таких свойств и полей значения модификаторов доступа заданы явно. Так что к серьезным проблемам это не должно привести.

VD>Можно пойти на такое решение только для свойств. Их то уж точно очень редко приватными делают. А протектед прописывается в явном виде. Так что вообще проблем не будет.

VD>ЗЫ

VD>В общем, это как идея. Я не настаиваю. Просто правильные соглашения могли бы сократить код не причиняя вреда. Одна проблема — усложнит ли это понимания.

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

VD>Для мьютабл-данных это не обсуждается даже. Я бы вообще запретил их публичными делать, была бы моя воля .
А сложно будет реализовать такое ограничение, которое можно было включать и выключать по выбору для отдельного Н-проекта?

Здравствуйте, VladD2, Вы писали:

VD>В одной из дискуссий с этого форума была высказана мысль, что private-поля для структур по умоланию неудобны.

В структурах в принципе можно сделать аналогично С++ публичными по умолчанию

VD>Откровенно говоря не вижу разницы между структурами и классами. На мой взгляд изменяемые поля нужно прятать от народа и делать их по умолчанию водимыми — это зло (провокация нарушения инкапсуляции).

VD>Однако для неизменяемых полей и для свойств — это не так. Неизменяемые поля и свойства в 99% случаях объявляются для описания публичного интерфейса.

VD>Может быть было бы разумно изменить для них умолчания и делать их по умолчанию public?
В принципе это можно сделать, действительно mutable стиль программирование используется все реже, и язык сам функциональный больше чем императивный, в вариантах писать поля просто. Также потребность на практике действительно отпадает в реад-онли свойствах и присутствия закрытых неизменяемых полей. Только если это не будет слишком вызывающим в объектно-ориентированном сообществе.

Здравствуйте, Аноним, Вы писали:

А>Извиняюсь за предыдущее пустое сообщение, хотел авторизоваться, а случилась отправка коммента.

VD>>Для мьютабл-данных это не обсуждается даже. Я бы вообще запретил их публичными делать, была бы моя воля .
А>А сложно будет реализовать такое ограничение, которое можно было включать и выключать по выбору для отдельного Н-проекта?

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

Здравствуйте, Аноним, Вы писали:

VD>>Для мьютабл-данных это не обсуждается даже. Я бы вообще запретил их публичными делать, была бы моя воля .
А>А сложно будет реализовать такое ограничение, которое можно было включать и выключать по выбору для отдельного Н-проекта?

Сделай макрос уровня сборки. Ищи в нем все типы и назначай свои дефолты. Работы на пол часа.

Здравствуйте, VladD2, Вы писали:

VD>Может быть было бы разумно изменить для них умолчания и делать их по умолчанию public?

Это плохая идея. Усложняет правила языка (если в поле в классе, то оно по умолчанию приватное, иначе если оно мутабл, то оно по умолчанию приватное, а иначе публичное — сложновато) и отдаляет его от С#, ничего не давая взамен. Менять класс на структуру (или наоборот) станет неудобно (даже опасно).

Еще мне кажется, что делать поля элементом интерфейса даже структур довольно опасная идея. И если уж программист так делает, то он должен это явно указать.

А вот если (была такая идейка) использовать синтаксис полей для свойств, а для полей использовать ключевое слово field, то появляется пространство для маневра.

Здравствуйте, catbert, Вы писали:

C>Это плохая идея. Усложняет правила языка (если в поле в классе, то оно по умолчанию приватное, иначе если оно мутабл, то оно по умолчанию приватное, а иначе публичное — сложновато) и отдаляет его от С#, ничего не давая взамен. Менять класс на структуру (или наоборот) станет неудобно (даже опасно).

Я не говорил о введении различий для структур и типов.

C>Еще мне кажется, что делать поля элементом интерфейса даже структур довольно опасная идея. И если уж программист так делает, то он должен это явно указать.

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

C>А вот если (была такая идейка) использовать синтаксис полей для свойств, а для полей использовать ключевое слово field, то появляется пространство для маневра.

Можно пока что говорить только о свойствах.

Здравствуйте, Don Reba, Вы писали:

DR>Соглашение по оформлению кода от команды RSDN указывает, что модификаторы доступа должны быть прописаны явно

Что не мешает иметь значений по умолчанию. К тому же эти правила написаны для шарпа в котором мы (по понятным причинам) ничего исправить не можем.

DR>Если и разрешать не указывать модификатор,

Это уже разрешено. И в C# в том числе. Так что это даже не обсуждается.

DR>то надо делать это также как и C#, чтобы не удивлять лишний раз начинающих.

Вот это уже аргумент. Только вот начинающие могут быть не из C#. Да и умолчания вряд ли удивят, если они логичные.

Здравствуйте, catbert, Вы писали:

C>Это плохая идея. Усложняет правила языка (если в поле в классе, то оно по умолчанию приватное, иначе если оно мутабл, то оно по умолчанию приватное, а иначе публичное — сложновато) и отдаляет его от С#, ничего не давая взамен. Менять класс на структуру (или наоборот) станет неудобно (даже опасно).

Нет Влад говорит что любые поля становятся публичными по умолчанию, если программист решил сделать mutable поле публичным то это ничем не отличается от того если бы он создал публичным свойство, этим он декларирует что поле можно изменять извне, таких проблем которые есть в С++ в Н нет, с полем кроме изменения ничего проделать плохого нельзя (взять адрес например), поэтому в Н эти опасения неактуальны. Если программист делает публичным поле, по ошибке, опустив модификатор, то это чисто логическая ошибка невнимательности. Если он пишет mutable перед до этого реад-онли публичным полем, то он и указывает свои намерения явно. Писать дизайн полей класса просто в этом случае дело привычки. Хотя mutable поля плохой стиль программирования в функциональном языке в любом случае.

C>Еще мне кажется, что делать поля элементом интерфейса даже структур довольно опасная идея. И если уж программист так делает, то он должен это явно указать.
Что опасного в реад-онли полях, в вариантах они прекрасно используются по умолчанию и никому проблем не доставляют.

C>А вот если (была такая идейка) использовать синтаксис полей для свойств, а для полей использовать ключевое слово field, то появляется пространство для маневра.
Вот вводить новый синтаксис, не очень хорошая идея, мы идем к упрощению, а новые ключевые слова, только усложняют дизайн.

Здравствуйте, VladD2, Вы писали:

VD>Всем привет.

VD>В одной из дискуссий с этого форума была высказана мысль, что private-поля для структур по умоланию неудобны.
VD>Откровенно говоря не вижу разницы между структурами и классами. На мой взгляд изменяемые поля нужно прятать от народа и делать их по умолчанию водимыми — это зло (провокация нарушения инкапсуляции).
VD>Однако для неизменяемых полей и для свойств — это не так. Неизменяемые поля и свойства в 99% случаях объявляются для описания публичного интерфейса.
VD>Может быть было бы разумно изменить для них умолчания и делать их по умолчанию public?

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

Неизменяемые поля могут быть ссылками на изменяемые объекты. Если умолчания будут зависеть еще и от типа поля — будет совсем неочевидно.
Часто используемый паттерн:

class SomeClass
{
  private readonly ISomeService _someService;
  
  public SomeClass(ISomeService someService)
  {
     if(someService == null) throw new ArgumentNullException("someService");
     _someService = someService;    
  }
  
  //...
}

Этот _someService — совсем не задумывается как часть публичного контракта класса.

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

Здравствуйте, catbert, Вы писали:

C>Здравствуйте, VladD2, Вы писали:

VD>>Может быть было бы разумно изменить для них умолчания и делать их по умолчанию public?

C>Это плохая идея. Усложняет правила языка (если в поле в классе, то оно по умолчанию приватное, иначе если оно мутабл, то оно по умолчанию приватное, а иначе публичное — сложновато) и отдаляет его от С#, ничего не давая взамен. Менять класс на структуру (или наоборот) станет неудобно (даже опасно).

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

Здравствуйте, artelk, Вы писали:

A>Этот _someService — совсем не задумывается как часть публичного контракта класса.

OK. На счет полей уговорили.

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

Я предлагаю изменить умолчальный доступ на публичный для всех свойство в любых типах.

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

Тут логика очень простая. Публичность свойств может сделать декларации более чистыми. Кому охота читать тонны одинаковых префиксов перед реальной декларацией?
Вот ввели в немерле module-и и описывать утилитарные статические методы стало намного удобнее.

VD>Может быть было бы разумно изменить для них умолчания и делать их по умолчанию public?

если согласится с умолчанием для свойств publiс, встает вопрос об таком же умолчании для методов. что будет логично и последовательно.
надо скрывать-ограничивать — пожалста, пиши. у 50% языков так. у других так. одни обязывают все указывать, другие не требуют.
вопрос заключается в только в сокращении описания, семантика не затрагивается.

Здравствуйте, _Claus_, Вы писали:

VD>>Может быть было бы разумно изменить для них умолчания и делать их по умолчанию public?

_C_>если согласится с умолчанием для свойств publiс, встает вопрос об таком же умолчании для методов. что будет логично и последовательно.
_C_>надо скрывать-ограничивать — пожалста, пиши. у 50% языков так. у других так. одни обязывают все указывать, другие не требуют.
_C_>вопрос заключается в только в сокращении описания, семантика не затрагивается.

Конечно хардкод и того и другого в компилятор дело противоречивое, лучшим выходом и для методов является макрос, который меняет видимость членов у которых не указаны модификаторы, например:

class Test
{
[Visibility(Public)]

Method1() : void
{
}

property : int {get;set;}
}

[VisiblityDefault(Public)]
class Test2
{

Method1() : void
{
}

property : int {get;set;}
}

Я уже писал подобный макрос, можно его указывать перед частью объявлений как в C++, (при желании можно сделать на уровне типов, и на уровне сборок). Это позволяет вручную контролировать семантику и не писать нудные повторяющиеся модификаторы для группы объявлений. Владу не понравился синтаксис, неочевидно что после макроса видимость другая. Проблемы с синтаксисом нет на уровне типов, проблемы же с синтаксисом в классе наверное можно решить в Н2, если будет возможность указать специальный синтаксис для этого макроса. А так можно юзать это решит обе проблемы, упростить ввод повторяющихся модификаторов, и не менять умолчания в существующих проектах.
Кому интересно, примерный код макроса можно посмотреть здесь: https://github.com/CodingUnit/CommonLib/blob/master/CommonLib/CommonLib.Nemerle/CommonLib.Macros/Visibility.n