RM
namespace Directories {
std::string ModulesPath;
}Друг мой, вы слишком часто выбираете неймспейсы, когда вопрос заходил о классах. Это сишное направление, а не ООП
Size: a a a
2020 August 21
🦊
Ты пихаешь ООП туда, где он не имеет вообще никакого смысла.
FO
Ты пихаешь ООП туда, где он не имеет вообще никакого смысла.
Нужна процедурщина на Фортране?
🦊
Это не Java, а C++. Тут есть более фундаментально простые конструкции нежели классы, на которых в жабе все сделано, ибо ничего другого нет.
FO
Это не Java, а C++. Тут есть более фундаментально простые конструкции нежели классы, на которых в жабе все сделано, ибо ничего другого нет.
Ну точно Фортран нужен
🦊
Да хоть Ada.
🦊
Тут адепт был (ну вот, уже словарь у царя спиздил)
RM
Это не Java, а C++. Тут есть более фундаментально простые конструкции нежели классы, на которых в жабе все сделано, ибо ничего другого нет.
Это неудобно в больших проектах использовать имена полей
🦊
Это неудобно в больших проектах использовать имена полей
[citation needed]
🦊
Это мнение человека, который не работал с большими проектами?
RM
[citation needed]
То что ты предлагаешь приведет к тому, что разработчики будут вынуждены обращаться к полям, чем юзать понятные имена методов, которые говорят за себя
🦊
SetHui(1) <==> Hui =1GetHui() <==> Hui🦊
Я тебе, впрочем, указал допустимый юзкейс для сеттер-геттеров в крестах.
🦊
У тебя всё будет так?
RM
SetHui(1) <==> Hui =1GetHui() <==> Huiconst hui& GetHui() const noexcept или m_hui ?RM
Что информативней?
🦊
Второе.
🦊
Первое содержит слишком много информационного мусора, который увеличивает время на восприятие кода разработчиком.
RM
Первое содержит слишком много информационного мусора, который увеличивает время на восприятие кода разработчиком.
Смешно, кинь пропс, пусть в С++30 уберут квалификаторы и аттрибуты
🦊
Я не сказал, что квалификаторы фундаментально чем-то плохи, не смей пихать слова мне в рот.