LINUX.ORG.RU

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

 , ,


1

3

SUBJ.

not necessary to use static function http://quickgit.kde.org/?p=kdepim.git&a=commitdiff&h=cce44af4dab14b49...

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

Don't use static variable http://quickgit.kde.org/?p=kdepim.git&a=commitdiff&h=13e7ad2f7ec0b5bd...

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

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

fluorite ★★★★★ ()

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

intelfx ★★★★★ ()

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

const86 ★★★★★ ()

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

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

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

static variable - зло.

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

dib2 ★★★★★ ()

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

GblGbl ★★★★★ ()
Ответ на: комментарий от emulek

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.

emulek ()

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

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

yoghurt ★★★★★ ()

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

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

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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 );
    }
}

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

anonymous ()
Ответ на: комментарий от anonymous

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

anonymous ()
Ответ на: комментарий от Gvidon

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

anonymous ()
Ответ на: комментарий от anonymous

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

Gvidon ★★★★ ()
Ответ на: комментарий от const86

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

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

anonymous ()
Ответ на: комментарий от smt

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

snoopcat ★★★★★ ()
Ответ на: комментарий от smt

Поддерживаю

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

kiotoze ★★★★ ()

1) Тесты

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

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

stevejobs ★★★★☆ ()
Ответ на: комментарий от stevejobs

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

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

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

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

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

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

Adonai ★★★ ()
Ответ на: комментарий от Adonai

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

stevejobs ★★★★☆ ()
Ответ на: комментарий от stevejobs

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

bottle of facepalm oil

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

Deleted ()
Ответ на: комментарий от Gvidon

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

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

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

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

anonymous ()
Ответ на: комментарий от stevejobs

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

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

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

emulek ()
Ответ на: комментарий от emulek

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

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

const86 ★★★★★ ()
Ответ на: комментарий от const86

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

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

emulek ()
Ответ на: комментарий от Deleted

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

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

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

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

stevejobs ★★★★☆ ()
Последнее исправление: stevejobs (всего исправлений: 1)
Ответ на: комментарий от dib2

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

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

jtootf ★★★★★ ()
Ответ на: комментарий от jtootf

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

dib2 ★★★★★ ()
Ответ на: комментарий от Deleted

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

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и.

stevejobs ★★★★☆ ()
Последнее исправление: stevejobs (всего исправлений: 2)
Ответ на: комментарий от stevejobs

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

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

Deleted ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.