Объясните, в чем профит таких коммитов?

KDE, сэр.

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

Разработчика в детстве покусали статическими функциями. Другое объяснение придумать затрудняюсь.

Статичная переменная может внезапно инициализироваться позже, чем в неё смотрят. Можно всё семь раз отмерять и много думать. А можно просто использовать функции или убрать глобальные объекты. Не знаю, тот ли случай сейчас. И вообще не знаю, чем им статичные функции не угодили.

Вместо использования static function создают объект и используют его функции.

для инкапсуляции данных?

Вместо static variable наплодили функций.

static variable - зло.

// код не смотрел

Ну, после джавы это не выглядит таким уж странным

Don't use static variable http://quickgit.kde.org/?p=kdepim.git&a=commitdiff&h=13e7ad2f7ec0b5bd... Вместо static variable наплодили функций.

подумай, что получится, если функция выполняется в двух нитях СРАЗУ.

PS

The strtok_r() function is a reentrant version strtok(). The saveptr argument is a pointer to a char * variable that is used internally by strtok_r() in order to maintain context between successive calls that parse the same string.

On the first call to strtok_r(), str should point to the string to be parsed, and the value of saveptr is ignored. In subsequent calls, str should be NULL, and saveptr should be unchanged since the previous call.

Different strings may be parsed concurrently using sequences of calls to strtok_r() that specify different saveptr argu‐ ments.

в чем профит таких коммитов?

в том, чтобы потом тыкать в них пальцем и говорить «смотрите, я контрибьютор кадэе!»

Вместо использования static function создают объект и используют его функции.

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

Вместо static variable наплодили функций.

Потокобезопасно.

П.С. а вообще код ужасный и перегруженный, не то они вычищают.

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

QWebElement TableHelper::tableBodyWebElement(const QWebElement &element)
 {
     const QString tagName(element.tagName().toLower());
     if (tagName == tableStr()) {
         QWebElement tableElement = element.firstChild();
         while (!tableElement.isNull()) {
             if ( tableElement.tagName().toLower() == tbodyStr() ) {
                 return tableElement;
             }
             tableElement = tableElement.nextSibling();
         }
         return QWebElement();
     } else if (tagName == tbodyStr()) {
         return element;
     } else {
         QWebElement e = element;
         do {
             e = e.parent();
         } while( (e.tagName().toLower() != tbodyStr()) && !e.isNull() );
         return e;
     }
 }

Хотя можно сделать, например, так:

QWebElement TableHelper::tableBodyWebElement( const QWebElement& element )
{
    switch( element.id() ) {
        case QWebElement::tbody : return element;
        case QWebElement::table : return element.findChild( QWebElement::tbody );
        default                 : return element.findParent( QWebElement::tbody );
    }
}

Компактно, просто и быстро.

Не обязательно добавлять в QWebElement то, что я написал (таки это публичный класс), это же можно сделать отдельными функциями и перечислением.

http://doc.qt.io/qt-5/qwebelement.html
Покажи мне здесь метод id

Ты мой второй комментарий видел, или бегом отвечать?

Тогда в коде будет такая же портянка if'ов, только в другом месте

Статичная переменная может внезапно инициализироваться позже, чем в неё смотрят.

Для этого придётся смотреть до main.

static -> global -> evil

А чем константные статические переменные в конкретной единице трансляции (.cpp) лучше или хуже функций в этой же единице трансляции?

какой же ужасный этот ваш опенсорц!
смотришь и удивляешься — а как это вообще работает ><

в closed-source хоть не видишь этого кошмара, «работает и ладно» и тешишь себя надеждой, что внутри не такой п-дец

Поддерживаю

Еще если используется тестирование - статика тоже сильно мешает

1) Тесты

2) Многопоточность

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

1) Тесты

2) Многопоточность

"- Приборы?!
- 15!" (ц)

что?

Это из анекдота.

Петька и Чапаев взяли судно на абордаж, перебили всех белых. Через некоторое время поняли, что никто из них управлять кораблём-то не умеет. Ну, импровизация, Чапаев за штурвал встал, Петьку в машинное отделение послал. И тут на тебе - шторм. Чапаев сквозь ветер орёт вниз:

- Петькаа-а! Прибооор!?

- Пятнаа-а-адца-ать!!

- Что пятнадцать?!?

- А что прибор?!

эээ, ну чтобы писать тесты, нужно делать mock'нутые объекты. А как ты их сделаешь, если метод статический? Нормальные пацаны вместо статических методов юзают dependency injection. В джаве для этого есть Spring например. Какбе это очевидно любому кто пишет тесты.

в Java не рекомендуется использовать статические методы совершенно вообще никогда.

bottle of facepalm oil

особоенно в случах вида Objects.equals(value1, value2)

Тогда в коде будет такая же портянка if'ов, только в другом месте

Небольшая поправка - это будет в одном месте, а результат можно сохранить для оптимизации. Ну и очевидно там будет не портянка из if, а что-то вроде:

static const QHash<QString, QWebElementId> h {
   { "tbody" , QWebElement::tbody },
   { "td"    , QWebElement::td    },
   ....
}

По стандарту С++11 это потокобезопасно, да и таблицу можно вообще вынести в глобальную переменную для микрооптимизации. В чем тут отличие от QString, который вынесли в функцию - QString шарит буфер между несколькими экземплярами, чтоб не делать полное копирование, а это таки непотокобезопасно. Тут же вернется целое, а в процессе поиска ничего в const QHash не изменится - значит безопасно.

можно объяснить подробней?

что там объяснять?

вот объект который состоит из нерекомендуемых методов: https://docs.oracle.com/javase/8/docs/api/java/util/Objects.html

их там тысячи, и конкретно этого класса ждали наверное с момента первого релиза явы

Не знаю как в C++, а в Java

не знаю как в жабе, а в C++ в этом нет никакого криминала, если конечно статический метод закрытый. Вот только такие методы тупо не нужны, только для статических полей. Т.е. статический метод ничем не отличается от обычной функции в C стиле. Но есть плюс: видна такая функция только в своём классе. Правда есть пространства имён…

Интерфейс из статических методов очень быстро скатывается в говно. Потому я открытые статические методы никогда не юзаю.

Если коротко: ФГМ

Но есть плюс: видна такая функция только в своём классе. Правда есть пространства имён…

Один годный случай использования статичных функций в классе: чтобы потом этот класс передавать как параметр в шаблон. А так да, обычные функции вполне годные.

Один годный случай использования статичных функций в классе: чтобы потом этот класс передавать как параметр в шаблон.

спасибо, я как-то не подумал об этом.

1) Там в джаве/jdk говнокода просто непроходимые говны :) Ты б еще Apache Commons привел в пример хорошего кода :)

2) @Inject/@Autowired - сильно многословная вещь, чтобы использовать ее постоянно. Потому что уродский язык! Ничего, к Java10 всё поправят :)

3) Может это как-то связано с тем, что для некоторых людей оверхед, принесенный динамическим связыванием в рантайме недопустим (всякие встроенные системы)?

4) Еще, ты пользовался CDI? Я - нет. Может быть, это просто неюзабельная фигня? А Спринг пока не часть JDK. Этот CDI вообще нормально работает вне application-контейнера?

для инкапсуляции данных?

вот так и выглядит ООП головного мозга: объект это инкапсуляция, инкапсуляция это хорошо. то, что данных тут нет, никого не смущает

то, что данных тут нет, никого не смущает
// код не смотрел

ты по ссылке вообще ходил?

Самообман это плохо.

Ходил. Вот тебе версия без статических методов:

class A {
    @Inject Objects o;

    @Test
    public void asd() {
       B b = new B();
       assertEquals(o.hash(b), 123);
    }
}

Общее правило простое: все синглтоны, фактори, статики и прочие зависимости нужно реализовывать через (заменять на) Dependency Injection, где это хоть сколько-то возможно (не будет ударом по перфомансу). Написанный таким образом код можно удобно метапрограммировать в динамике. Если хит по перфомансу, то так и быть, погружаемся по уши в говны.

Но мне кажется, что такой синтаксис очень неудобный. Хотелось бы нечто вроде:

class A {
    @Test
    public void asd() {
       B b = new B();
       assertEquals(@Objects.hash(b), 123);
    }
}

Чтобы @-референсы сразу запускали динамический поиск по implicit-символам. Заодним чтобы были implicit methods, implicit parameters, implicit classes, итп. Может даже implicit macros чтобы писать DSLи.

Вот тебе версия без статических методов:

которая не работает в голой jre и в несколько порядков медленнее, просто потому что в _любой_ объект реализующий hashCode придется что-то инжектить через рефлекшен