Russian Qt Forum

Мы привыкли как дурачки писать mData (m_data), потом инлайнить доступ к ним. Да зачем? Лишь потому, что прочитали в *надцатом году (а все остальные переписали это), что данные должные быть скрыты . Понятно, есть преимущества сокрытия, если захотим добавить проверку, не надо в коде ничего менять. Оставим также попытку сделать проперти частью плюсов, без гет/сет многие покончат жизнь самоубийством.

О чём рассуждения - о том, что Qt даёт имена переменных класса без всяких префиксов и не страдают от этого.

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

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

Для горячих голов - это говорилка, ни о чём, нехочу мир менять, не хочу кому что либо доказать, не хочу пену у кого либо у рта.

Хм, интересный поток сознания, раньше такого не встречал) И давно это у вас началось?

Мы же уже в Вами общались по этому поводу. Вашим ответом на это сообщение вы становитесь участником этого фееричного (подберите нужные слова себе) потока сознания, в котором не хотите участвовать (налицо противоречие). Если есть замечания конкретные (и короткие), то добро пожаловать.

А вообще прикольно конечно. Хех. Подойду к вам с другой стороны (не с зада) - 6 тысяч сообщений, тут тоже стоит задуматься.......

Не надо говорить за всех.  ;)

Ну, я этим числом не горжусь, оно само как-то накопилось.

А вот различать в 40 параметрах приватные и публичные члены очень даже помогает при отладке :)

Сеттеры и геттеры легче отлаживать, чем обращение к публичному члену - 1 брекпоинт вместо поиска всех обращений.

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

PS мантру про inline увеличивают код не слышал. А разве нет?

Согласен, визуальная составляющая здесь играет далеко немаловажную роль.

Ну тут тоже возразить нечего.

Тогда проигнорируем это.

Вы ответили в контексте практики, и тут я с вами ЗА. Но сокрытие переменных - это идеология.

Также замечу, что переменные должны быть  (по идеологии) в приват. Протектед не приветствуется. Ну и как тут психоз не получить? Т.е. если я метод в протектед засунул (повышение области видимости просто) - это допустимо, а переменная - это "недопустимо". Понятно. Мы все ходим кругами при написании кода и плюём на все правила, когда "устали". Мы так часто плюём на правила, что хотим стремиться к идеалу, к тем устоям программирования. Так по пути следования к ним (к этим долбанным устоям), занимаясь всяким очередным рефакторингом у нас возникает сомнения -  блин, ну тоска какая-то.

Не вижу ничего плохого в этой идеологии. Есть плюсы, есть минусы.

Но само распространение этой идеологии - лишь большой пребольшой плюс, который обощает кучу кода :)

А я вижу. Есть состояние объекта (его переменные), есть перевод состояние объекта в другое стабильное состояние (его методы).
В плюсах нету разделение между переменными и методами (в плане языка, мы то знаем, где что).

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

Вот это поворот)

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

Ты давно в исходники Qt заглядывал ?  :o

Так устроен мозг, это нормально - и без "дурачков" пожалуйста. Когда человек с чем-то знакомится впервые - он должен что-то запомнить, тупо, на веру. По-другому не выходит, для какого-то осмысления/анализа нет еще ни  знаний, ни опыта. Эти первые запомненные вещи - очень яркие воспоминания, поэтому человек обычно следует им даже когда опыта достаточно. Да, иногда это противоречит здравому смыслу - напр маниакальные геттеры/сеттеры, но что поделаешь - инерция. Но в общем и целом ничего плохого нет, не видел ни одного хоть сколько-нибудь убедительного примера который побудил бы меня "отказаться от мертвых догм" :) Можно упираться сколько угодно типа "вот говорят goto плохо, а я БУДУ его писать, БУДУ!!!" - но дальше "попытки пооригинальничать" дело-то не идет

В плюсах нету разделение между переменными и методами



Почему поворот. Есть устойчивое словосочетание - гетеры/сетеры. Значит уже есть разделение на методы гетеры/сетеры и все остальные. В С++ вызов метода гет не отличается от вызова другого метода. Один из положительных мометов ввода проперти мы отделяем методы работы со всем классом с методом работы с конкретной переменной класса (пусть даже она  вычисляется налету). В каждом классе есть такие явные методы, которые мы определяем просто бросив взгляд на класс: isActive, isOpen, get/set Color. Предполагается, что они работаю только с одной переменной класса (в действительности это может быть не так, но вы же смотрим не на реализацию, а на интерфейс класса.

Если сложно выразился, то для меня в чем + - мы скрываем переменные, а выглядят они как открытые. Это первый момент.
Второй момент читаемость кода. Какая читаемость скажете вы? Все уже 100 лет пишут и читают нормально. Тогда приведу пример с перегрузкой операторов. Любую перегрузку можно заменить каким либо методом, но блин, читаемость как ухудьшится!

Не вижу причин ввода какой то третьей сущности.
Язык даёт нам методы и переменные. Каким манером вы проперти реализуете? :)
Отдельные геттеры сеттеры ? :P

Вчера, а вы?
Не встречали в коде Qt this->var = var?

Вот пример
class QRect {
private:
    int x1;
    int y1;
    int x2;
    int y2;

}

Начнем с того, что пропети  в Qt реализованы, и каким либо макаром их реализовывать уже не нужно (я про Qt, т.е. действительно гет/сет). Но!, я бы добавил в язык возможность проперти без методов гет/сет, т.е. доступ нарямую. Когда надо, добавим в проерти эти методы гет/Сет. И не забывайте, что даже если только через гет/сет, эти самые гет/Сет ушли бы из видимости. Это что-то вроде перегрузки операторов, только я не знаю какое название подобрать. Пусть будет "оператор присваивания переменной класса". И в методе гет отпадёт нужность в 90% случаях.

А вы в курсе что проперти это переменная с геттером и сеттером в Qt? :)

Я там в прошлое сообщение подкорректировал, прочитайте.
Конечно в курсе, это ж "расширение" языка, а не новый язык. По другому нельзя. Глупо было бы, если через метаданные мы могли бы значение получить, а через обычный метод нет, тем более Q_OBEJCT нужен. Да и вообще он для других целей, для доступа "извне" или через скрипты, а не программирования внутри.

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

Логики не видно.

И ваше высказывание, что он "внутри" не нужен - это вы погорячились наверно :D

Вот контр пример :

C++ (Qt)
class QSignalBlocker
{
public:
    inline explicit QSignalBlocker(QObject *o);
    inline explicit QSignalBlocker(QObject &o);
    inline ~QSignalBlocker();
 
#ifdef Q_COMPILER_RVALUE_REFS
    inline QSignalBlocker(QSignalBlocker &&other);
    inline QSignalBlocker &operator=(QSignalBlocker &&other);
#endif
 
    inline void reblock();
    inline void unblock();
private:
    Q_DISABLE_COPY(QSignalBlocker)
    QObject * m_o;
    bool m_blocked;
    bool m_inhibited;
};

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

class Color
public:
   property тип color:read mColor write setColor()
private:
   void setColor;
   тип mColor  

Во первых, мы не ищем пару гет/сет
Во вторых, мы не видем set
В третих, мы можем просто написать без set, а когда нужно добавить его.

Что такое метод гет? в 90% случаев - это inline color() const { return mColor; } или человеческим языком повышаем область видимости из приват в паблик со спецификатором const. Хорошо, пусть я предлагаю следующее

inline &color() { retrun mColor; }

color() = "red", где оператор =  перегруженный оператор, вызывающий setColor, как то так, не ругайте за псевдокод.

Давайте я вам приведу ещё пример

class Test
public:
    const QString name;
    Test(const QString n): name(n)

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



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

Мы же не соревнуемся, кто больше найдёт. Я говорю что они спокойно осознано игнорируют правила и не заморачиваются на это.
Редкая птица у них метод get  с префиксом get, вы заметили? Set - да, гет - очень редко.

И еще о мозге: его емкость очень ограничена. Занимаясь фигней типа "писать get или как?" - для работы места уже не остается. Вы, батенька, бездельник  :)

Если вы можете поддерживать тот уровень проверки кода, имеете такую же базу подписчиков ищущих баги - можете даже от сеттеров отказаться :D
Эта "идеология" позволяет одиночке или группе облегчить жизнь и дебажинг ценой пары строк. А вы восстаёте против неё )

Создавайте свою технологию, идеологию, внедряйте в массы - никто не запрещает. Но пока что я вижу лишь доказательства "от противного".
Т.е. ощутимых плюсов для людей/разработки/дебагинга/читаемости кода вы не описываете. Вы берёте старую идеологию и клевещите на неё :)

Я давно убедился, и меня никто не переубедит (и я никого не хочу переубеждать). Но самая сложная вещь в программировании, которой нужно уделять как можно больше времени (и которая его и съедает) это не какие то рекурсии, лямбды и иерархии классов. Самая сложная вещь это давать имена классам, функциям и переменным. Сложнее ничего нету и не будет.


А вы не завидуйте.

Мдя. Ни на что я не клевещу. А давайте пойдём от обратного. Почему бы не сделать , ведь это никак не может отменить пару гет/сет.
Конечно от обратного я иду. Проперти дополняют гет/сет, а не заменяют его. Я же не говорю убираем геты/сеты и только проперти ставим. И никуда я не воставал. Я вообще про именование переменных писал внутри класса и что очень много догм, которые мы придерживаемся для "чтобы осталось время на творчество, а не мозги включать там где не надо".а

Да и дался вам этот дебаг. Я не вижу разницы между инлайном и проперти в плане дебага. Одно и тоже. И дебажится будет на ура.

Да и про читаемость кода я говорил, однозначно она повысится.

Не видите ну и ладненько :)

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

Не убедительно..
Во-первых, механизм проперти легко реализуется и средствами самого языка, вот упрощённый вариант:

C++ (Qt)
#include <iostream>
#include <functional>
 
template <class T, class Obj>
class property
{
public:
    typedef std::function<T(Obj*)> getter_t;
    typedef std::function<void(Obj*, const T&)> setter_t;
 
    void init(Obj* obj, getter_t get, setter_t set)
    {
        object = obj;
        getter = get;
        setter = set;
    }
 
    property& operator=(const T& val)
    {
        setter(object, val);
        return *this;
    }
 
    operator T() const { return getter(object); }
 
private:
    Obj* object;
    getter_t getter;
    setter_t setter;
};
 
 
class test
{
public:
    test()
    {
        intProperty.init(this, &test::get, &test::set);
    }
 
    property<int, test> intProperty;
 
private:
    int value;
    int get() const
    {
        std::cout << "test::get() const" << std::endl;
        return value;
    }
    void set(int val)
    {
        std::cout << "test::set(int)" << std::endl;
        value  = val;
    }
};
 
int main()
{
    test t;
    t.intProperty = 123; // здесь будет вызван метод void test::set(int)    
    int a = t.intProperty; // здесь будет вызван метод int test::get() const 
 
    return 0;
}
 

Теперь мы можем работать с проперти как с открытым членом класса (почти!), но при этом будут вызываться соответствующие сеттеры и геттеры.
Но реально, нам всё равно необходимо писать самим эти сеттеры и геттеры для каждого проперти и регистрировать их..
Число строк кода не сократилось, а напротив.. Стал ли он от этого более наглядным, читабельным?
Реально что дают проперти - это "синтаксический сахар" не больше..

Но у проперти есть и свои минусы. Предположим у нас появился соблазн (в примере выше) иметь возможность делать инкремент и декремент, например:

C++ (Qt)
t.intProperty++;
 

Это уже не сработает.. Придётся в классе property реализовывать эти операторы.. Но дело в том, что не для каждого типа они имеют смысл (представьте, что property имеет тип QString или QVector или).
И это только один из примеров.





 

Тут не в реализации дело, а в принятии сообществом данных вещей. Заметте, принципиально не говорю про другие языки программирования, т.к. всё таки С++ стоит отдельно "от всех". Опять все повторяют о ухудшении читаемости. Это не так.

Видно идти нужно малыми шагами.
Переменная объекта. Только реад онли внешне.
Где ухудшение читаемости и увеличение кода?

class
public:
   property state read mState
private:
  mState
 

Все таки, если задуматься, вы конечно правы про ограничения. Тот же ++i. Тут сложности ещё те, может поэтому.....

Вы предлагаете увеличить количество кода, сложность кода, ради "не писать геттер". А смысл?

Да просто нет никакой особой потребности для введения проперти в с++. К тому же этот механизм реализуется средствами самого языка.
Хотите проперти - пожалуйста..

А Вы пример с сеттером привидите..)

Ну это вопрос комфортности языка. И на чистом С тоже можно писать ООП.


Усложняем задачу

class
public:
   property state read mState write setState   
private:
  setState(state) { mState = state }
  mState

Если нужен виртуал, меняем приват на протектед с соответствующим ключевым словом.

Также прошу обратить внимание, у нас пропал из области видимости сетер. Т.е. можно прозрачно менять это всё дело, не тревожа основной код. Мы понимаем, что данные сетер (в примере) не отличается от прямого доступа, но в реальности там есть всегда проверки.

Скорее вопрос синтаксического сахара.. И здесь я уже упоминал о тех ограничениях с проперти..
В плюсах работает принцип бритвы Оккамы, и это один из плЮсов плюсОв)

 
Ну и чем это принципиально отличается от того примера выше, что я приводил?

Я предлагаю уменьшить количество кода, а также его сложность, чтобы легче дебажить, когда я могу заменить одно другим.
Давайте смотреть правде в глаза. Вы прекрасно понимаете, что "появилась идея, быстрей кодить"  с опытом проходит. Нефиг садится за комп без плана действий. Также вы прекрасно понимаете, что проект (проект как документацию)  программы создать невозможно. К примеру проект дома можно, таких строились тысячи. ПО - никогда. Нет, его делают, но от первоначального вида рожки да ножки остаются. Поэтому мы ходим этими грёбаными кругами, проектируем, отвергаем, опять по новому кругу. Короче рефакторинг. И без него, без планового рефаторинга, будет абзац. (кроме программы калькулятор). Мы создаём структуры и все такое. Структура - это же наш класс дебажный, и мы себе говорим - закроем потом переменные. Мне бы это упростило жизнь, если бы были проперти.

Так, ничем. Кроме проперти. Вы пытаетесь реализовать нереализуемое. Я приведу пример. Где вы видели систему сигналов/слотов кроме Qt. Им понадобилось десятилетие, чтобы мы все "забыли", что сигналы и слоты это не часть С++ и библиотеки Qt, это просто реализация, которую каждый может реализовать в своей программе. Так понятно? Это целая культура, которая поначалу отвергалась.

Также приняты умные указатели, которые каждый может сам реализовать. Вы разницу видите? Т.е. вопрос как не стоит, вопрос стоит почему.

Ой, нет, не надо навязывать всем свою идеологию как за истину в последней инстанции..

Вот я смотрю чужой код, в котором автор направо и налево использует проперти.

C++ (Qt)
object.value = 123;
 

То что value - это проперти сразу так совсем не очевидно.. Казалось бы безобидное присваивание, но последствия этого могут кардинально изменить состояние всего объекта..
И ищи потом свищи, что потом пошло не так, что оказывается такое присваивание дёргает закрытый метод, который что то там ещё и делает исподтишка..
Не очевидность того, что происходит здесь и сейчас в когде - это как то явно в разрез с тезисом "легче дебажить"..    

Эмоционально слишком и не продумано. А вы и не должны знать, вызывается там какой то метод или нет. Вы установили значение объекта, пусть он сам реагирует. Я вообще не вижу разницы между вашим примеро и object.SetValue(123). Потом ищи свещи, что сет валуе дёргает закрытый метод, который что то там ещё и делает исподтишка. Так и перегрузку операторов отменим ещё, мало ли что там "+" делает.

Да и вообще, забудьте про идеологию. Прочитайте начало топика.

Что значит не реализуемое? Я же привёл код который в точности воспроизводит механизм проперти)

В boost'е, например, и здесь на этом форуме https://www.gitorious.org/lightssp (https://www.gitorious.org/lightssp)
И что?
А вы понимаете разницу между тем: что является непосредственной частью языка и каких либо реализаций (те же умные указатели) с помощью его же (языка) средств?
Это разные вещи.
Вы же нам категорически пытаетесь навязать (на примере проперти), чтобы они стали частью языка.


    

Разница в том, что когда я увижу в коде строчку

C++ (Qt)
object.SetValue(123)
 

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

Прочитайте начало топика. Первый пост.
Я, что, к вам пришёл домой и паяльником стал угражать, пишите все с проперти? Или здесь сидит Страуструп и читает мои сообщения и думает - а это ИДЕЯ! Я просто высказываю свои мысли на расслабоне, сегодня суббота, весна настала, птички поют, а вы про какое-то навязывание.

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

И про нереализуемое - вы слишком буквально воспринимаете слова.

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

И по поводу "быстрей кодить" - кодить надо быстрее. Да, нужно продумать архитектуру перед этим, но дальше пишется всё тот же код, который в вашем случае будет увеличиваться.

PS и вообще, что спорим то о неубитом медведе - сделайте нам тестовый пример с возможностями пропертей. Рабочий пример. 

Рассуждения зашли в тупик. Какая искусственная сущность? Вы употребляете слова - гетеры/сетеры. Вот это искуссвенно. Вы эмулируете уже проперти. Какие примеры? Это что, новое что-то? да в других языках есть, куда примеры то приводить.

Вы сделайте и мы посмотрим :) Почему у других есть, а у нас нету.

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

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

При виде такой строчки: a.value=10; вы будете морально готовы к тому, что это может быть property.

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

Эм, о чем это я? +1 за property на уровне языка в плюсах. К примеру, в шарпе отличные property.

Опять, сделайте сделайте. Да в инете кучу примеров и десятки реализаций. Но не являясь частью стандарта они принесут геморой, а не красивость кода. Кстати, только что узнал, что MS их в своем компиляторе поддерживает. Правда, опять же, они мне не нужны только от МС.

Подытожу: проперти для меня дают ясность и прозрачность кода, вместо
string.append(string2)
вы пишете string + string2. Вы же не жалуетесь, что перегрузка операторов от вас "что-то скрывает". (проперти в данном примере не причем, я привел как метафору)

Вообще не понятно, как люд пережил появление в стандарте переменной auto.

Да, да) Лямбды всякие, вариадик темплейт, move конструкторы и операторы, decltype и прочее ненужное барахло)

Так вы завели разговор чтобы мы поправили стандарт C++?
Или вы смотрите в столь отдалённое будущее?

Вообще то я не против, чтобы вы подправили стандарт с++. Если можно, внесите в черновик. Я понимаю, что ждать долго, но всё же!

Давайте будем честными. Представте, что лет 5 назад я начинаю тему здесь:

Переменные auto  в с++.  Мол так и так, давайте введём такую переменную.

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

Я тоже не могу оценить все фитчи новые, а лишь потому, что с++ окаменел надолго.  Трясти его почаще надо, тогда и стрельбы в ногу будут более элегантными.

К жабе питаю глубокую неприязнь, но как бы хотелось иметь ихний "implements" :) Эх, если бы еще пару штучек из лиспа... Думается таких предложений масса у любого кто хоть как-то знаком с др языками.

Ну в общем-то да :) Сами по себе вещи это интересные и полезные, но у меня сложилось стойкое впечатление что Вы занимаетесь только ими. Типа как ребенок питается только витаминами (по 2 пачки в день), ну и конечно в результате постоянный диатез, понос и хуже  :)

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