Показать сообщение отдельно
  #58 (permalink)  
Старый 28.12.2014, 13:23
Аспирант
Отправить личное сообщение для fancy Посмотреть профиль Найти все сообщения от fancy
 
Регистрация: 16.12.2014
Сообщений: 67

Сообщение от kogarashisan Посмотреть сообщение
Я оставляю свою схему именования через подчеркивание, так как это является хорошей практикой.
Хотя бы один пример, где это является хорошей практикой.
В php?
Да в php это хорошая практика.

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

Сообщение от kogarashisan Посмотреть сообщение
Вы предлагаете мне именовать переменные в классе так же как методы - как тогда отличать методы от переменных? Если смешаны методы и переменные - то код превращается в мусорку.
Плохие примеры: JQuery, Grunt.
Я не предлагаю делать в стиле JQuery и прочих. Исходники и плагины на JQuery действительно похожы на мусор (:
Надеюсь никого не обидел.

Сообщение от kogarashisan Посмотреть сообщение
Здесь все не так. Код, который вы пишете под Lava - является частью фреймворка. Вы расширяете фреймворк своей функциональностью. Поэтому, здесь никогда не будет Lava.config() - здесь будет только то, что вы можете переопределить и повторно использовать.
Звучит как просто добавить в прототип метод.
Ну нормально.

Сообщение от kogarashisan Посмотреть сообщение

Поскольку в JavaScript нет понятия приватности - их принято именовать с подчеркиванием.
И это свойство может быть учтено, скажем, при сжатии - их можно свободно переименовать
внутри класса и его наследниках, так как извне они вызываться не должны.
Ты хорошо объяснил, что у меня не получилось.
Если оно будет учтено при сжатии, то зачем эту функции в API добавлять.
О чем весь разговор, что принято именновать подчеркиванием приват.
А у тебя все приват получается.

Сообщение от kogarashisan Посмотреть сообщение
Про $

Если переименовывать родительские методы - то делать это по какому-то алгоритму.
Мой текущий алгоритм: <название_родителя> + "$" + <название_метода>.
Есть другие варианты?

Сообщение от fancy
Можно ввести внутри фреймворка список кратких названий переменных.
А можно как в EXT.JS - там сотни всяких alias'ов. Тем кто уже не первый год этой фигней страдает, тем конечно хорошо, а вот новичкам не очень.
alias - это алтернативное название класса.
Пример:
Ext.Panel, Ext.panel.Panel
Оно скорее нужно, просто для удобства. и проблемы нет никакой в этом.

Про сокращенные именования.
Это просто для удобства.

Ну если тебе так не удобно, то ладно.
Если вот это удобно...
removeGlobalHandler: function(listener) {

		var event_name = listener.event_name,
			index = this._event_handlers[event_name].indexOf(listener);
		if (Lava.schema.DEBUG && index == -1) Lava.t();
		this._event_handlers[event_name].splice(index, 1);

		this._event_usage_counters[event_name]--;

		if (this._event_usage_counters[event_name] == 0) {

			this._shutdownEvent(event_name);

		}

	},
        _createEventWrapper: function(event_name) {

		var self = this,
			freeze_protection = this._freeze_protected_events.indexOf(event_name) != -1;

		// I'm not sure about this, but looks like the argument should be specifically named "event"
		// [url]http://stackoverflow.com/questions/11188729/jquery-keyup-event-trouble-in-opera[/url]
		// see also this to understand the roots of such behaviour:
		// [url]http://stackoverflow.com/questions/4968194/event-keyword-in-js[/url]
		return function(event) {
			self._onDomEvent(event_name, event, freeze_protection);
		};

	},
       _initEvent: function(event_name) {

		this._event_listeners[event_name] = this._createEventWrapper(event_name);

		if ((event_name in this._dom_event_support) && this._dom_event_support[event_name].delegation) {

			Firestorm.Element.addDelegation(window, event_name, '*', this._event_listeners[event_name]);

		} else {

			Firestorm.Element.addListener(window, event_name, this._event_listeners[event_name]);

		}

	},


Мне такой вариант, не айс...

Думаю больше я тебе никаким советом помочь не смогу.
Не надо, ну значит не надо
На данном этапе я твоим продуктом пользоваться не буду как минимум
потому что
1 - API - жесть
2 - Что-нибудь расширить добавить - это возиться с пунктом 1.
3 - Ошибки в работе даже с тем примером который на странице.


Про другие пункты.
Короче делай как хочешь, успехов
В любом случае наберешься опыта.

Последний раз редактировалось fancy, 28.12.2014 в 13:39.
Ответить с цитированием