- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
package aerys.minko.scene.node.group
{
...
public class LoaderGroup extends Group implements IEventDispatcher
{
...
public static function loadBytes(bytes : ByteArray, parserOptions : ParserOptions = null) : LoaderGroup
{
return new LoaderGroup().loadBytes(bytes, parserOptions);
}
...
public function loadBytes(bytes : ByteArray, parserOptions : ParserOptions = null) : LoaderGroup
{
...
minko, конечно, интересный 3д движок с нестандартными решениями, но вот такие выебоны вгоняют в ступор. я даже не знал, что такое компилится.
why?
/ftfy/
Каюсь - сама так иногда пишу
вот в данном случае - создается обьект, который загружает данные, при этом данные возвращаются, а загрузчик безвозвратно отправляется в мусорный контейнер
Я такие конструкции часто пишу когда проектирую структуру, под рефракторинг. Потом они благополучно умирают, когда добавляется функционал.
Грамотно с точки конкретного момента, но не факт что в уме автора нету знаний о том как это все будет расширятся.
Этот код - вполне грамотный.
хватит приставать к женщинам :-Р
Я вижу говнокод в том, что можно было сделать так:
Т.как вторая функция все равно ничего нового к первой не добавила. Недостаток - не известен тип аргументов функции. Я в таком случае делал бы:
Но это зависит от того, знакомы ли разработчики с HaXe / согласны ли они мирится с тем, что код будет не до конца проверятся компилятором и т.п.
Но, вообще, если чесно, я не вижу надобности во второй функции - зачем, если она ничего принципиально нового не делает?
Имена, согласен, лучше бы разные использовать.