Для примера, проверить наличие метода " URL.createObjectURL " можно 3 способами:


Но с объектами FileReader и FormData беда какая-то. Ни один из способов не работает.
Например, нужно проверить наличие методов (которые гарантированно поддерживаются всеми современными браузерами):


Как проверить ?

авторпроверить практически все что угодно можно с помощью метода обработки ошибок try-catchДля того, чтобы можно было проверить существование метода с помощью try...catch , нужно:
а) подготовить тестовые (но реальные) данные для выполнения проверяемого метода (получить объект File , содержащий ссылку на реальный файл, либо создать объект FormData )
б) выполнить реальную команду путём вызова метода и передачи ему реальных данных
в) различать типы ошибок, поскольку в процессе выполнения реальной команды могут быть сгенерированы ошибки, не связанные с НЕсуществованием метода

В итоге все эти действия превращаются ни во что иное, как в "тяжёлую" заплатку, которую вряд ли кто реализовывает с целью решения сабжевой задачи...

Да, тоже подумал про прототипы. Через прототипы работает нормально .

В случае с URL проверку необходимо выполнять через объект URL , а не через его прототип (прототип имеет тип URLPrototype ), поскольку методы URL.createObjectURL() и URL.revokeObjectURL() прописаны в самом объекте URL , а в его прототипе отсутствуют:


Но в случае с объектами FileReader и FormData - наоборот. Проверяемые методы присутствуют в их прототипах, но отсутствуют в самих объектах (не являются их собственными свойствами):


Но здесь непонятно, почему обращение к этим методам непосредственно через сами объекты возвращает unfdefined , ведь при обращении к свойствам и методам объекта при отсутствии собственных методов должно производиться обращение к методам прототипов.

авторНо в случае с объектами FileReader и FormData - наоборот. Проверяемые методы присутствуют в их прототипах, но отсутствуют в самих объектах (не являются их собственными свойствами)Да, здесь нужно поправиться: не " отсутствуют в самих объектах ", а " отсутствуют в функциях-конструкторах этих объектов " (а в самих объектах - присутствуют).

Т.е. в случае с windows.URL.createObjectURL выполняется обращение к "статическому" свойству-функции " createObjectURL " функции-конструктора " windows.URL ".

И поскольку FileReader и FormData являются функциями-конструкторами без статических методов, а методы " readAsDataURL() " и " append() " - это свойства-функции объектов-прототипов FileReaderPrototype и FormDataPrototype соответственно, то проверить наличие эти методов можно двумя способами:

1. Через прототип функций-конструкторов FileReader и FormData :

2. Через прототип объектов "классов" FileReader и FormData (объектов, созданных функциями-конструкторами FileReader и FormData ):


Поскольку свойство "__proto__" стандартизовано только в ECMAScript 6 , плюс создание объектов - это лишняя трата ресурсов, то предпочтителен вариант №1 .

[quote автор]skyANACyrax_02а в самих объектах - присутствуют
Нет. Они определены в прототипе, ссылка на который копируется в __proto__ при создании объекта через new.Строго говоря, да. Но под " в самих объектах - присутствуют " я имел ввиду видимость этих методов непосредственно из объектов
А объявлены (и физически существуют/присутствуют) они, конечно, в прототипах.

авторТогда уж вариантом номер два должен быть тот, что выше предложил Тshаmil: 20592353. Его вариант - это вообще без явного обращения к прототипам. Мои два варианта - с явным обращением к прототипу.

Кстати мой 2-й вариант может иметь смысл (как альтернатива 1-му) в том случае, когда объект уже создан (для неких иных целей).
При этом конструкция с " in " семантически более понятна и прозрачна, чем определение типа свойства-функции " typeof ... readAsDataURL ".
Но имеет минусы (свойство " __proto__ " стандартизовано только в ECMAScript 6 )

skyANACyrax_02, а можете толком объяснить, зачем нужно явное обращение к __proto__ во втором случае?

У меня на в консоли true , а у Вас?Согласен. К __proto__ обращаться вообще не нужно ))

Т.е. имеем 2 варианта: