Нашли или выдавили из себя код, который нельзя назвать нормальным,
на который без улыбки не взглянешь?
Не торопитесь его удалять или рефакторить, — запостите его на
говнокод.ру, посмеёмся вместе!
Вывод типов генериков (особенно до диамондов), возможность потом прозрачно сделать так чтоб возвращало разные подтипы (см. EnumSet=> RegularEnumSet vs JumboEnumSet ) и просто плюшки в виде обхода разных ограничений конструкторов.
Тут засада в том, что в js конструктор от обычной функции можно отличить только в момент вызова (конструктор - new Foo(), функция - Foo()). Ну и соответственно map никак не узнает, что надо дёрнуть эту функцию как new Foo() и вызовет её как обычную функцию Foo(). В this попадёт Window (в браузерах) и функция насрёт в глобалки, вернёт undefined и не покажет ошибок...
P.S. Ну можно делать комбо-конструкторы, которые и как new Foo() и как Foo() работают... Но, имхо, это то ещё говно.
Конструкторы никак не маркируются. Рантайму похуй. Ты любую функцию можешь вызвать как new SomeFunction(), при этом запилится объект, который будет доступен в SomeFunction() как this. Вот такой вот жс.
Дык это просто отметка о том, какую функцию new заюзало как "конструктор" при запиливании объекта...
Это совершенно не мешает делать new Foo() на любой функции и вызывать "конструкторы" как Foo()... Апофеоз слабой тупизации... Но адептам, наверное, нравится такая свобода.
Ну да. Просто в жс с точностью до наоборот - по вызову понять можно, а по описанию никак не понять, будет это конструктор или нет. Ну только косвенно: вроде в this чё-то пишет, наверное это конструктор (или вдруг всё же просто метод, да хуй его поймёт...)
P.S. Ну и то, что по вызову нельзя отличить - это даже плюс иногда. Вон в примере wvxvw с мапом. В питоне ты там можешь передать конструктор, а можешь просто функцию. И всё будет ок без всяких оборачиваний в лямбду...
P.S. + соглашение, что конструкторы пишутся с большой буквы, а методы - нет 🙂
> + соглашение, что конструкторы пишутся с большой буквы, а методы - нет 🙂
Вот это - сомнительная штука по-моему. Потому, что часто неясно, это конструктор или преобразование.
x = Integer(y); vs x = toInteger(y);
В идеале надо скрывать конструирующий побочный эффект конструктора, делегировать разруливание компилятору, оставляя программисту просто функцию. Ну и запиливать аналог экстеншн методов. Чтоб каждый мог написать свой "конструктор" для объекта и вызывать Integer(myObject). В C++ хотя бы в описании своего ярко выраженного типа можно описать как бы конструктор другого типа; жаль, для произвольного нельзя в виде свободной функции.
О, тут столько обсуждения...
Ну какбы тут связывание ни при чем. Тут речь о том, что нельзя использовать конструктор как функцию (а иногда хочется).
Более того, с точки зрения типов, конструктор - это что-то непонятное. Т.е. вот функция: она понятная, у нее есть тип Range -> Image, а у конструктора вроде тоже есть точно такой же тип, но синтаксически его нельзя использовать там, где можно использовать любую другую функцию.
Нормальная практика, тащемта. В той же жабе есть подобный valueOf().
Завёз пруфы
Effective Java (2nd edition) - библия жаболюбов:
Item 1: Consider static factory methods instead of constructors
Но если это, например обычный конструктор типа:
то нужно уже так:
P.S. Ну можно делать комбо-конструкторы, которые и как new Foo() и как Foo() работают... Но, имхо, это то ещё говно.
Ложки нет.
Конструкторы никак не маркируются. Рантайму похуй. Ты любую функцию можешь вызвать как new SomeFunction(), при этом запилится объект, который будет доступен в SomeFunction() как this. Вот такой вот жс.
> Ложки нет.
Это совершенно не мешает делать new Foo() на любой функции и вызывать "конструкторы" как Foo()... Апофеоз слабой тупизации... Но адептам, наверное, нравится такая свобода.
P.S. Ну и то, что по вызову нельзя отличить - это даже плюс иногда. Вон в примере wvxvw с мапом. В питоне ты там можешь передать конструктор, а можешь просто функцию. И всё будет ок без всяких оборачиваний в лямбду...
P.S. + соглашение, что конструкторы пишутся с большой буквы, а методы - нет 🙂
Вот это - сомнительная штука по-моему. Потому, что часто неясно, это конструктор или преобразование.
x = Integer(y); vs x = toInteger(y);
В идеале надо скрывать конструирующий побочный эффект конструктора, делегировать разруливание компилятору, оставляя программисту просто функцию. Ну и запиливать аналог экстеншн методов. Чтоб каждый мог написать свой "конструктор" для объекта и вызывать Integer(myObject). В C++ хотя бы в описании своего ярко выраженного типа можно описать как бы конструктор другого типа; жаль, для произвольного нельзя в виде свободной функции.
тем не так часто это фича нужна
Ну какбы тут связывание ни при чем. Тут речь о том, что нельзя использовать конструктор как функцию (а иногда хочется).
Более того, с точки зрения типов, конструктор - это что-то непонятное. Т.е. вот функция: она понятная, у нее есть тип Range -> Image, а у конструктора вроде тоже есть точно такой же тип, но синтаксически его нельзя использовать там, где можно использовать любую другую функцию.