GCC - трюки/вопросы
 

Давайте в этом треде писать вопросы/трюки и т.д. при работе с GCC.

Вопрос:

Как декларировать перегрузку параметров метода при переопределении метода в дочернем объекте.

Решение:

Это конечно хак, но работает:

/** @constructor */
function Foo() {}

/**
 * @param {string} a
 * @param {...?} args
 * @return {string}
 */
Foo.prototype.get = function (a, args) { return ''; }

/**
 * @constructor
 * @extends {Foo}
 */
function Foo2() {}

/**
 * @override
 * @param {number} b
 */
Foo2.prototype.get = function (a, b, e) { return ''; }

Т.е. в родительском классе мы закладываем декларацию о возможном расширении

@param {...?} args

Мб есть более правильный способ?

kobezzza, по-моему, всё верно. или я не понял :)

хм. я вижу, что там обновилась статья о JSDOC внутри GCC.

Что думаете насчёт того, чтобы дополнить статьи на сайте?

Ну это скорее хак, чем нормальное решение :)

Имеешь ввиду здесь на javascript.ru?

в учебнике.

там какие-то шаблоны типов; структуры - походу из C принесли в GCC. нипанятна

Почему бы и нет:)

Скорее из Java - это реализация генериков, но я на практике эти конструкции тоже не юзал.

Задал вопрос на трекере GCC:

Overloading parent method

Support of parameter objects

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

Заведём функцию ковертор:

/**
 * Вернуть заданный объект с указанием произвольного типа
 * (для приведения типа в GCC)
 *
 * @param {?} val - исходное значение
 * @return {?}
 */
function Any(val) {
	return val;
}

Теперь допустим у нас есть функция:

/**
 * @param {(string|!Array)} idOrParams
 */
function get(idOrParams) {
    if (Array.isArray(idOrParams)) {
        return idOrParams.map(...); // Тут GCC начнёт варнить, мол тип может быть строкой и данный код не безопасен
    }
}

Решение номер 1

Сделаем явную конвертацию данных:

/**
 * @param {(string|!Array)} idOrParams
 */
function get(idOrParams) {
    if (Array.isArray(idOrParams)) {
        return [].concat(idOrParams).map(...);
    }
}

Работает, но выглядит как кривой хак (а вот для конвертаций в примитивы можно спокойно юзать Boolean, String и Number).

Решение номер 2

Использование конвертора Any

/**
 * @param {(string|!Array)} idOrParams
 */
function get(idOrParams) {
    if (Array.isArray(idOrParams)) {
        /** @type {!Array} */
        var myArray = Any(idOrParams);
        return myArray .map(...);
    }
}

Функцию Any GCC грохнет при компиляции и никаких оверхедов не будет, данный трюк можно использовать для любой кновертации данных, также можно наплодить на основе Any ряд функций, навроде: isArray и т.д.

есть ли веские прчины использовать экстримальное сжатие gcc изрщряясь с jsdoc и кодом? сжатие на дополнительных 30 киллобайт вполне компенсируется gzip. или я что то не так говорю? ДАЖЕ СРАНУЮ КАРТИНКУ сожми чуть сильнее, и вот тебе окупилось отсутсивие gcc

он вкупе ещё и неплохо меняет форму кода (не просто инлайн функций)

ну а юзать - имхо, UglifyJS2 в руки и нормас. он (углифи) и работает быстрее

Ну для мне меня это в первую очередь валидатор и оптимизатор (сжатый код в среднем работает на 20% быстрее). В целом GCC дисциплинирует и пропагандирует написание понятного и быстрого кода.

работает быстрее? но ведь от сжатия логика не меняется, за счет чего?

За счёт хардкода, микрооптимизаций и инлайнинга, в Advanced Mode GCC моожет генерить свои функции, удалять исходные и т.д., т.е. работает как оптимизирующий компилятор.

Нет код написаный с поддержкой адвенсед оптимизаций GCC не понятен, и не читабелен. это минус его. К тому же такой код заставляет ДУМАТЬ о нем. А человек не должен думать о коде а должен думать о программе. Вот я и говорю, этот минус ради чего стоит терпеть?
Получил ответ - код работает быстрее. То есть по сути можно написать нормально код, а горячие места переписать под GCC или что? Не имеет ведь смысла оптимизировать весь код, нужн оптимизить только горячие места. Не имеет смысла получать тот минус, и не получать плюс. А плюс от "на 20% быстрее" срабатывает только в горячих местах, если не горячее место станет работать на 20% быстрее то плюс от этого не окупит минус от этого.

Окей, на сколько я знаю. Невозможно входить в адвансед режим только в определенных местах, и придется писать ВЕСЬ код в стиле GCC.

Напомню что это минус и мы хотели бы этого избежать. Мы хотели бы писать код в свободном стиле а не в стиле CGG. Писать код в стиле CGG минус. И ни кто этого не сможет опровергнуть и не пытайтесь. Кто попытается тот долбоеб. Кто говорит что такой код лучше и понятнее - долбоеб. Кто говорти что это не минус а плюс - долбоеб. Эту тему не поднмиаем. Если вы хотите МЕНЯ разубедить в этом то у вас не получится, если хотите для других что то подоказывать, то вперед.

Итак. Синтаксис CGG нужно ТЕРПЕТЬ и МУЧИТЬСЯ от него, только при условии что он окупится.

Пока на чаше весов у нас вот что:

Минусы - нужно писать код в особом стиле.
Плюсы - код работает на 20% быстрее.



ВОТ ЛИЧНО Я трачу ООЧЕНЬ много ресурсов мозговых когда буду писать под GCC и их ускорение в 20% еле еле окупит и то не всегда. Если человек тратит НЕ ТАК МНОГО МОЗГОВЫХ ресурсов на такой стиль кода, тогда его выбор очевиден.

Итак, встроенный оптимизатор хрома неужели глупее чем GCC? Неужели вебкит не достаточно умен чтобы сделать внутри себя все те же оптимизации? А так же, Возможно ли писать в обычном абстрактном понятном стиле, а при дебаге только горячеие места оптимизировать руками? Сравнится ли результат по скоростьи с результатом GCC?

вообще, тебе никто не говорил, что это прям must have suka. все равно либы подключают в dev режиме и сами потом сжимают

имхо он нужен в крайних случаях - сейчас можно и углифи оттвикать, да скрипты в GZIP пожать и через SPDY отдать. времена меняются :)

нет. атомарные функции, разделение ответственности... все это GCC заставит тебя использовать, если этого ты еще не используешь, говнокодер

чем больше ты думаешь о коде, тем лучше он получится

... тем более, что рефакторить под GCC ты будешь параллельно с обычным рефакторингом

а уметь писать хороший код - надо.

когда я компилял ядро на телефон (да, я и такой хернёй занимался), я думал, что для компилятора хватит -Ofast.
но когда я увидел -flto, я просто ахренел. это была тема! (не обьясняю, что это. лучше погугли)

GCC от гугла - примерно тот же flto, но для JS. (очень грубо говоря)

ну ты тут сам себе ответил:
... запиливаешь юнит тесты, системные тесты и рефакторишь код

Единственное, что требует GCC Adv - это jsDoc, который помимо всего прочего даёт офигенный профит при статическом анализе и идеальный автокомплит в ИДЕ.

https://github.com/kobezzza/Collecti...ib/core/obj.js

Где вот здесь, например, треш-GCC код?

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

Ясно, на лицо синдром "GCCниасилус".

ты просто тупой, cgg заставит тебя писать jsdoc и еще много лишнего синтаксиса, но ты на столько тупой что не понял этого

лучше должен получаться не код, а программа.

нужно как можно меньше думать о коде, и как можно больше думать о программе, как например в coffeescript

Нет, он требует уродства вроде чтобы функция не затерлась и не изменила имя надо её то ли ['name'] = func делать, то ли еще что то, на этом сайте есть целая статья посвященая таким извращениям. Или она устарела и это все уже через jsdoc сделать можно и я зря гоню?

п.с. писать jsdoс опять же лишняя работа если результат этого не окупит. писать jsdoc не для GCC а по каким либо другим причинам нет смысла.

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

Автокомплит и статический анализ в IDE, автогенерация доки и ещё много чего. Я пишу всегда и довёл до автоматизма этот процесс.

Помню, когда я хвалил кофескрипт, ты писал что я тупой долбаёб и кофескрипт не очевиден, кажется ситуация повторяется вновь...

Илья кантор значит обманул меня когда писал учебник. Я поверил ему и думал что я разбираюсь в теме. От сюда и непонмиание)

:D :D :D :D я так и знал что ты мне это припомнишь))) нет нет тогда я жил во тьме и не ведал что тварю, с тех пор я открыт всему новому) по этому и слушаю тебя

Не, прошел год, кофескрипт по прежнему прекрасен) а GCC не нужен :D