- 1
- 2
- 3
- 4
private function onClick(e:MouseEvent):void
{
dispatchEvent(new MouseEvent(MouseEvent.CLICK, true, false))
}
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
−99
private function onClick(e:MouseEvent):void
{
dispatchEvent(new MouseEvent(MouseEvent.CLICK, true, false))
}
Еще один кусочек очень полезного кода. (this для этого обработчика - MovieClip).
Fai 30.10.2012 11:24 # +2
wvxvw 30.10.2012 15:04 # 0
Lure Of Chaos 31.10.2012 00:31 # +1
кстати, на два одинаковых кейса ругательств не будет? джава так точно ругаеца
wvxvw 31.10.2012 00:50 # 0
ЗЫ. Неа, как ни странно, даже предупреждения такого нет. Хотя могли бы. С другой стороны, разрешено выражения в кейсах, и полноценной проверки компилятор не сделает, т.как он даже обычную арифметику не умеет. Так что если бы там, например было:
компилятор это уже не рассекретил бы.
Но я думаю, что есть PMD утилита, которая может это отлавливать.
Lure Of Chaos 31.10.2012 01:04 # 0
wvxvw 30.10.2012 15:10 # +1
3.14159265 30.10.2012 18:11 # +2
Всё прям как Тарас диагностировал:
КрасныйКвадрат, ЗеленыйКвадрат.
roman-kashitsyn 30.10.2012 18:19 # +1
LispGovno 30.10.2012 18:55 # +1
roman-kashitsyn 30.10.2012 19:07 # +5
LispGovno 30.10.2012 19:19 # −1
Мне не нравится этот вариант с шаблоном, тк IDE будет везде подсвечивать тип переменных как Square<Color::Green>, а не как GreenSquare, тк к сожалению typedef не вводит новый тип.
Кто там пользовался новым стандартом? using появился там для объявления типов. При этом новый тип объявляется и IDE подсвечивает GreenSquare, а не Square<Color::Green>?
LispGovno 31.10.2012 00:14 # −5
TarasB 30.10.2012 20:12 # +2
TarasB 30.10.2012 19:02 # +2
Fai 31.10.2012 10:53 # +1
wvxvw 30.10.2012 19:03 # 0
Более того, я как бы это сейчас переписывать должен под Андроид, а там и размеров таких не будет, да и вообще все по-другому.
Lure Of Chaos 31.10.2012 00:32 # 0
> AnimationThumbClass
PublicClassAnimationThumbClassExtendsSli derThumbClassWithWidth19AndHeight22
guest 30.10.2012 21:59 # 0
Допустим у нас есть вертолет, который можно кликнуть и взорвать. Есть отдельно детонатор, клик по которому тоже взрывает этот конкретный вертолет. Пусть еще будет кнопка, которая взрывает вообще все.
Для того, кто следит за всеми этими кликами и убирает взорвавшийся вертолет со сцены, конечно, удобно когда он получает событие с event.target = вертолет который нужно убрать, а не с event.target = что-то, что вызвало взрыв. Наверно допустимо вертолету повесить несколько слушателей на детонаторы и передиспатчивать событие с собой в качестве таргета, вместо того, чтобы вертолетоубиралка.as следила за всеми связями, и понимала что от чего взрывается.
wvxvw 30.10.2012 23:06 # 0
wvxvw 31.10.2012 00:08 # +1
Не хотелось отдельным постом, не заслуживает оно столько внимания, но не мог не поделиться.
Lure Of Chaos 31.10.2012 00:33 # 0
wvxvw 31.10.2012 00:37 # 0
Ну и грамматические ошибки, которые даже и не выговоришь - тож неплохо.
Lure Of Chaos 31.10.2012 00:46 # 0
код не видел, но есть смутное подозрение, что это "не совсем" одно и то же, т.е. опять беда с архитектурой
> грамматические ошибки
скорее автору важнее сохранить написание корней, или просто не задумывался
wvxvw 31.10.2012 00:56 # 0
Lure Of Chaos 31.10.2012 01:03 # 0
bormand 31.10.2012 06:09 # 0
Инструмент выполнил недопустимое действие и будет завершен.
Fai 31.10.2012 11:38 # 0
Зачем вообще создавать интерфейс для каждой операции?
wvxvw 31.10.2012 11:50 # 0
Меня сначала немного удивил подход, но потом я понял, что картинки, как таковые, никогда не предполагалось сохранять, а только то, как они были сделаны. Конечно, там еще куча разных других косяков, включая самопальный формат сериализации и абсолютно нерабочий механизм отмены действий, но вцелом задумка жизнеспособная.
roman-kashitsyn 31.10.2012 12:08 # 0
Чтобы потом писать if (command instanceof IUndoable) ((IUndoable) command).undo();
3.14159265 31.10.2012 16:57 # +4
Так вот оказалось что
if (obj instanceof A) ((A) a).a();
if (obj instanceof B) ((B) b).b();
самый быстрый способ диспетчеризации вызова нужного метода.
Хз почему так. Но в 90% случаев вызовы виртуальных методов работают чуть-чуть медленее.
А в шарпе-то вроде виртуальность убрали по дефолту.
Мораль такая: любители ооп, которые на любое ветвление лепят полиморфизм вместо case or if в очередной раз соснули.
LispGovno 31.10.2012 17:18 # 0
3.14159265 31.10.2012 17:26 # +2
Если у нас 1 или 2 подкласса, то скорость примерно одинаковая. К моему превеликому удивлению увеличение количества наследников (ну и след. ифов) сильней снижает скорость полиморфного кода. Вот пруф, например:
http://www.javaspecialists.eu/archive/Issue158.html
А после 3-х ифов нативный instanceof начисто порвал полиморфные вызовы.
Уж не знаю как нынче на 1.7, но на 1.6 было так.
PS. А Case+Enum, так же неожиданно оказался пошустрее интерфейсов, настолько же неожиданно его обошли instanceof.
3.14159265 31.10.2012 18:32 # +2
http://www.theeggeadventure.com/wikimedia/index.php/InstanceOf_Performance
Сранение классов x.getClass() ==A.сlass непрактично по понятным причинам. Я такой вариант даже не рассматривал.
Как вы могли прочитать по сцылке выше - в серверном HotSpote случаи когда 1 и 2 наследника - оптимизируются. Это объясняет хороший результат на сервеной солярке.
Когда варинтов >2 - там слив. Я с десяток проверял.
Ну может если ветвление будет штук на 30 то if-else и сольют.
Но делать с 30 классов - это попахивает говнецом.