Лингвофорум

Чё-то Равонам умалчивает тот факт, что в Питоне есть такое понятие, как дескрипторы. Т.е. в питоне this.x = 10 тоже на самом деле может быть вызовом функции. И самый сок в том, что это непросто определить, т.к. весь язык построен на скрытых хаках. А в C# явно видно, что перед нами свойство, т.е. если боишься, то всегда можно закешировать его.

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

А вообще мне они очень даже нравятся.

Питон и сшарп некорректно сравнивать, как их можно вообще в одной строке писать-то..

Самый скрытохакный язык — Жабаскрипт.

Цитата: RawonaM от декабря 23, 2010, 22:39
У всех свои предпочтения и язык дает возможность разных вариантам, что создает потенциальное злоупотребление и недопонимание.

Это неприменимо для C#. Нужно писать по установлённым порядкам: имена публичных членов с большой буквы, приватных — с маленькой. Приватные свойства не имеют смысла, т.к. свойства существуют только ради красоты интерфейса, поэтому свойства всегда с большой буквы. Иначе засмеют.

Цитата: RawonaM от декабря 23, 2010, 22:48
только указал на возможные их недостатки, которые иногда могут забрать в два раза больше времени, чем экономится на пропертизах вообще.

Я не понял, где ты указывал на их недостатки. Даже в яве и в питоне и в си мало кто использует поля для публичного интерфейса. Делают функции-обёртки (в си — макросы) вокруг полей. Сам-то класс может работать со своими полями напрямую. Свойства созданы чисто для интерфейса, и там я никаких недостатков не вижу. Конечно, если с какого-то перепугу использовать приватные свойства, то можно запутаться.

Цитата: Алексей Гринь от декабря 23, 2010, 22:51

ЦитироватьУ всех свои предпочтения и язык дает возможность разных вариантам, что создает потенциальное злоупотребление и недопонимание.

Это неприменимо для C#. Нужно писать по установлённым порядкам: имена публичных членов с большой буквы, приватных — с маленькой. Приватные свойства не имеют смысла, т.к. свойства существуют только ради красоты интерфейса, поэтому свойства всегда с большой буквы. Иначе засмеют.

Засмеют — не аргумент. Во-первых, как отличить публичный член от проперти — не ясно, даже если придерживаться правил. Во-вторых, чего ж тогда эти порядки не встроены в язык? "Нужно писать так, а то засмеют" — это детсад. Если язык позволяет вариации, значит каждая компания может решить использовать это по-своему.

Цитата: Алексей Гринь от декабря 23, 2010, 22:54
Я не понял, где ты указывал на их недостатки.

Ну что ж делать, не можем мы на 100% друг друга понимать. Значит проехали

Цитата: Алексей Гринь от декабря 23, 2010, 22:54
Свойства созданы чисто для интерфейса,

Ещё для избежания проблем с versioning.

Цитата: RawonaM от декабря 23, 2010, 22:56
Во-первых, как отличить приватный член от проперти — не ясно, даже если придерживаться правил.

Не понял. Если придерживаться правил, то свойство будет с большой буквы, а поле — с маленькой. Так и отличать.

Цитата: RawonaM от декабря 23, 2010, 22:56
"Нужно писать так, а то засмеют" — это детсад.

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

Цитата: RawonaM от декабря 23, 2010, 22:56
Если язык позволяет вариации, значит каждая компания может решить использовать это по-своему.

Если язык позволяет выстрелить себе в ногу, это не повод стрелять себе в ногу.
Я не видел ещё, чтобы кто-либо серьёзный писал на C# по иным гайдлайнам, чем установлено.

Цитата: Алексей Гринь от декабря 23, 2010, 23:04

ЦитироватьВо-первых, как отличить приватный член от проперти — не ясно, даже если придерживаться правил.

Не понял. Если придерживаться правил, то свойство будет с большой буквы, а поле — с маленькой. Так и отличать.

Я очепятался, уже там исправил. Публичный член.

Цитата: Алексей Гринь от декабря 23, 2010, 23:04

ЦитироватьЕсли язык позволяет вариации, значит каждая компания может решить использовать это по-своему.

Если язык позволяет выстрелить себе в ногу, это не повод стрелять себе в ногу.

Повод еще как. Иначе можно вернуться к бестипным языкам и вообще ниче не проверять, если че-то не так сделал ССЗБ — и досвидания. Языки должны быть максимально удобными и экономить время, а не заставлять думать, какой тут капкан может быть.

Цитата: Алексей Гринь от декабря 23, 2010, 23:04
Я не видел ещё, чтобы кто-либо серьёзный писал на C# по иным гайдлайнам, чем установлено.

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

И вообще, имхо самой банальной вещи в пропертях не хватает: индексаторов. Где-то читал, что в С-шарпе их убрали намеренно, хотя в васике и прочих дотнетах есть. Может в четверке уже одумались?

Цитата: RawonaM от декабря 23, 2010, 23:08

Цитировать

ЦитироватьВо-первых, как отличить приватный член от проперти — не ясно, даже если придерживаться правил.

Не понял. Если придерживаться правил, то свойство будет с большой буквы, а поле — с маленькой. Так и отличать.

Я очепятался, уже там исправил. Публичный член.

Терминология странная. Публичное свойство и есть публичный член. Имеется в виду поле? Как я уже сказал, в .NET публичные поля не рекомендуется использовать. Они допустимы разве что при P/Invoke при описании unmanaged structs, т.к. там инкапсуляция не нужна.
Во-первых, публичные поля не рекомендуются из-за возможных проблем с versioning, потому что логика может поменяться (напр., нужно полученный результат как-то изменить), а код везде (в том числе клиентский, если у нас библиотека) использует напрямую поле. Это ломание API.
Во-вторых, зачем вообще отличать поля от свойств? По гайдлайнам свойство должно производить гарантированно быструю операцию, т.е. оверхеда никакого не должно быть. Напр. поэтому в базовой библиотеке классов Object имеет метод GetHashCode, а не свойство HashCode, т.к. неизвестно сколько долго будет браться хеш, если переопределять метод в дочерних классах. Бояться, что а вдруг свойство будет думать минуту — это паранойя, которая на практике имеет мало смысла (с профайлером проблему легко найти).

Цитата: RawonaM от декабря 23, 2010, 23:09

ЦитироватьЯ не видел ещё, чтобы кто-либо серьёзный писал на C# по иным гайдлайнам, чем установлено.

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

Может, так и есть. Не читал стандарт C#'овский. Но вообще это правила общие для .NET'а, хотя и допустимо использовать собственные конвенции, напр. как это есть в F# (там много чисто OCAML-овых функций_в_известном_стиле). Вообще в .NET'е есть ещё такая штука, как CLS compliance. Её можно нарушать, а можно не нарушать — смотря какие цели. Там поумнее всё сделано всё-таки, чем в жабке, и не так всё лоботомично.

Цитата: RawonaM от декабря 23, 2010, 23:11
И вообще, имхо самой банальной вещи в пропертях не хватает: индексаторов. Где-то читал, что в С-шарпе их убрали намеренно, хотя в васике и прочих дотнетах есть.

Ну они редко когда нужны, а если нужны, то легко эмулируются аггрегацией.

Цитата: Алексей Гринь от декабря 23, 2010, 23:21
Во-вторых, зачем вообще отличать поля от свойств?

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

Цитата: Алексей Гринь от декабря 23, 2010, 23:21
Во-первых, публичные поля не рекомендуются из-за возможных проблем с versioning, потому что логика может поменяться (напр., нужно полученный результат как-то изменить), а код везде (в том числе клиентский, если у нас библиотека) использует напрямую поле. Это ломание API.

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

Впрочем, если на сегодня проперти определяется одной строкой и не отличается от переменной, а переменная создается имплицитно, то они вообще не отличаются.

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

Цитата: Алексей Гринь от декабря 23, 2010, 23:22
Там поумнее всё сделано всё-таки, чем в жабке, и не так всё лоботомично.

C этим согласен полюбэ.

Цитата: Алексей Гринь от декабря 23, 2010, 23:25

ЦитироватьИ вообще, имхо самой банальной вещи в пропертях не хватает: индексаторов. Где-то читал, что в С-шарпе их убрали намеренно, хотя в васике и прочих дотнетах есть.

Ну они редко когда нужны, а если нужны, то легко эмулируются аггрегацией.

Это как понять — легко? Мне нужно простую вещь сделать, а теперь эмуляцию строить...
Даю пример, буквально сегодня ломал голову. Я в С-диезе новичок, может че-то дельное подскажешь, чем просто языками трепать
Например, есть приватный массив допустим string a[]. Мне нужна пропертя, которая выдаст по индексу n — a[n][0]. Как это легко сделать? Получается, что если в лоб, то надо выдавать целый массив первых караткеров из того массива.

Геттеры и сеттеры отлично инлайнятся, если кто-то озабочен оверхедом на установку стекфрейма при вызове скрытого метода.

Цитата: Алексей Гринь от декабря 23, 2010, 23:38
Геттеры и сеттеры отлично инлайнятся, если кто-то озабочен оверхедом на установку стекфрейма при вызове скрытого метода.

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

Цитата: RawonaM от декабря 23, 2010, 23:30
Но когда разбираешь код класса какого-нибудь, нужно думать, вот тут присваивается проперти — а вдруг его сеттер делает какие-то действия?..

В таком случае (внутри класса) если имя идентификатора с заглавной буквы — то метод вызывается, если со строчной — то просто ставится поле.

Вообще конечно есть такая фигня, что геттеры и сеттеры у некоторых имеют слишком много побочных эффектов. Порицаю. Однако это не проблема C# совсем, а вообще всех языков.

Цитата: RawonaM от декабря 23, 2010, 23:30
Впрочем, с точки зрения инкапсуляции этого не надо знать.

В том-то и дело. Как раз-таки публичные поля — это выставление кишок на показ. В некоторых ООП-языка х (ЕМНИП, objc, smalltalk) публичные поля вообще запрещены. Не понятно об чём с пор: геттеры и сеттеры признаются негодными, т.к. не позволяют писать плохой код. Очень жаль!

Цитата: RawonaM от декабря 23, 2010, 23:30
Завтра че-то изменится — замени на проперти если надо, ничего менять в существующих кодах не надо, даже и перекомпилировать не надо.

Хм. Перекомпилировать надо, т.к. вызов свойства это вызов внутреннего метода get_XXX. Сделано это потому как некоторые языки не имеют категория свойства. На уровне байткода вызов поля это байткодина ldfld, а вызов свойства это байткодина calli.

Цитата: RawonaM от декабря 23, 2010, 23:30
Чтобы сделать ридонли поля проперти не обязательно было вводить.

Дык есть и ридонли-поля. Только проперти делают гораздо больше: 1) возможность объявления в интерфейсах 2) возможность переопределения в дочерних классах 3) возможность изменения поведения без ломания API 4) просто визуально красота. Куда лучше x.Prop += 1; чем x.setProp(x.getProp() + 1);

Цитата: RawonaM от декабря 23, 2010, 23:30
Если сеттеры и геттеры никогда ничего не делают помимо присвоения, то они вообще не нужны.

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

Цитата: RawonaM от декабря 23, 2010, 23:36
Например, есть приватный массив допустим string a[]. Мне нужна пропертя, которая выдаст по индексу n — a[n][0]. Как это легко сделать?

Чё-то не понял, что нужно.

Цитата: Алексей Гринь от декабря 23, 2010, 23:51

ЦитироватьВпрочем, с точки зрения инкапсуляции этого не надо знать.

В том-то и дело. Как раз-таки публичные поля — это выставление кишок на показ. В некоторых ООП-языка х (ЕМНИП, objc) публичные поля вообще запрещены. Не понятно об чём с пор: геттеры и сеттеры признаются негодными, т.к. не позволяют писать плохой код. Очень жаль!

Чем отличается публичное поле от public int a{ get; set; }?
Упрощаю парадокс: у сеттерах/геттерах возможно сделать все, но делать этого нельзя, кроме того, что делают эти дефолтные.

Цитата: Алексей Гринь от декабря 23, 2010, 23:51

ЦитироватьНапример, есть приватный массив допустим string a[]. Мне нужна пропертя, которая выдаст по индексу n — a[n][0]. Как это легко сделать?

Чё-то не понял, что нужно.

Помечтаем о суппорте индексов:
class C
{
private string a[];
public char A0[index]
{
   get { return a[index][0] }
}

void dummy()
{
char c = a[2][0];
char d = A0[2];
}
}

В итоге с и d должны быть равны.

Цитата: RawonaM от декабря 24, 2010, 00:06
Чем отличается публичное поле от public int a{ get; set; }?

Тем, что свойство public int Count { get; set; } может быть реализицией интерфейса

interface ICountable
{
    public int Count { get; set; }
}

Цитата: RawonaM от декабря 24, 2010, 00:06
но делать этого нельзя, кроме того, что делают эти дефолтные.

С чего хоть. Всё что угодно можно делать.

Пример из мира матриц:

        public Vector3 Scale
        {
            get
            {
                return new Vector3(this.M00, this.M11, this.M22);
            }
            set
            {
                this.M00 = value.X;
                this.M11 = value.Y;
                this.M22 = value.Z;
            }
        }

Цитата: RawonaM от декабря 24, 2010, 00:06
Помечтаем о суппорте индексов:

Это малость нетривиально, поэтому надо методом GetFirstChar.
Если сильно приспичит, то можно эмулировать созданием вспомогательного класса что-то вроде

Цитироватьpublic struct StringIndexer
{
    private string[] strs;
    internal StringIndexer(string[] strs) { this.strs = strs; }

   public char this[int index] { get { return strs[index][0]; } }
}

...

public StringIndexer A0
{
   get { return new StringIndexer(this.a); }
}

...

char d = A0[2];

В Winforms таким методом сделано определённое число классов с именованным индексатором (то есть реально возвращаются специальные объекты). По-моему, это не очень сложно, учитывая нераспространённость такого случая.

Цитата: Алексей Гринь от декабря 24, 2010, 00:21

ЦитироватьПомечтаем о суппорте индексов:

Это малость нетривиально, поэтому надо методом GetFirstChar.
Если сильно приспичит, то можно эмулировать созданием вспомогательного класса что-то вроде

Ж*** короче. Понятно, что классом можно сэмулировать, но мне это ни к селу ни к городу вообще.

Цитата: Алексей Гринь от декабря 24, 2010, 00:21
По-моему, это не очень сложно, учитывая нераспространённость такого случая.

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

Цитата: Алексей Гринь от декабря 24, 2010, 00:21

Цитироватьно делать этого нельзя, кроме того, что делают эти дефолтные.

С чего хоть. Всё что угодно можно делать.

Пример из мира матриц:

Вот, наделал там, а кто-то читает код и ниче не понимает, потому что куча операций имплицитно делаются. Следовательно, нельзя делать все что захочешь в функциях доступа.

Цитата: RawonaM от декабря 24, 2010, 00:29
Ж*** короче.

Да чё хоть жопа. Там класс вспомогательный аж 4 полноценных строчки. Напоминаю, что в яве просто тупо описать поле, поставить один бессмысленный сеттер и один бессмысленный геттер это уже 3 строчки.

Цитата: RawonaM от декабря 24, 2010, 00:29
Случай это не то чтобы нераспространенный, он вообще постоянно нужен. Без него проперти неполноценные ни разу. Если я хочу вернуть значение как функция от индекса, а не массив вернуть. Фигня в общем нездоровая.

Спорно.

Цитата: RawonaM от декабря 24, 2010, 00:29
Вот, наделал там, а кто-то читает код и ниче не понимает, потому что куча операций имплицитно делаются.

Всегда есть комментарии.

Цитата: RawonaM от декабря 23, 2010, 22:37
Автор может не помнить, если писал этот код пять лет назад, так же как и читатель не может ходить и смотреть сеттеры всех пропертиз. А проблем вообще никогда никаких нет, вопрос потраченного времени.

Тебе так и так придётся смотреть определение b и тратить на это время. Я вариант с ясновидением не рассматриваю, возможно, зря...

Цитата: RawonaM от декабря 23, 2010, 22:37
И нах это надо, если можно просто int a?

А как компилятор будет свойства от переменных отличать?

Цитата: RawonaM от декабря 23, 2010, 22:39
Все проблемы вообще надуманные и их никогда нет, если придерживаться строгих правил и все четко помнить наизусть. ИРЛ ситуация не такая, особенно когда над кодом работаешь возвращаясь к нему раз в несколько месяцев и код вообще не твой.

В таком режиме птичий код, напичканный сокращениями, вообще противопоказан. Это не ты его выше рекламировал?

Цитата: RawonaM от декабря 23, 2010, 22:48
Я только указал на возможные их недостатки, которые иногда могут забрать в два раза больше времени, чем экономится на пропертизах вообще.

Ты так и не привёл убедительных примеров.

Цитата: RawonaM от декабря 23, 2010, 22:48
Самый скрытохакный язык — Жабаскрипт.

?

Цитата: RawonaM от декабря 23, 2010, 22:56
Во-первых, как отличить публичный член от проперти — не ясно, даже если придерживаться правил.

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