2

Я хотел бы иметь способ указать для определенного метода Javascript, какие атрибуты необходимы, какой шаблон они должны соответствовать, и как реагировать, если они не являются.Есть ли библиотека Javascript для принудительной подписи методов?

Это связано с тем, что в результате получается много повторяющегося кода для проверки необходимых и необязательных параметров на уровне метода.

Возьмите этот пример. Здесь я хотел бы создать лайтбокс. Если они отправят мне строку, я покажу лайтбокс с просто содержанием. Если они отправляют мне объект опций, я ищу «заголовок» и «контент». Было бы здорово, если бы это можно было определить стандартизованным способом?

// Static method for generating a lightbox 
// callerOptions = '' //if sent a string, the lightbox displays it with no title 
// callerOptions = { 
//  content: '' // required popup contents. can be HTML or text. 
// , title: '' // required title for the lightbox 
// , subtitle: '' // optional subtitle for lightbox 
// } 
lightbox = function (callerOptions) { 
    if (!callerOptions) { 
     log.warn(_myName + ': calling me without a message to display or any options won\'t do anything'); 
     return; 
    } 

    // If they send us a string, assume it's the popup contents 
    if (typeof(callerOptions) === 'string') { 
     this.options = {}; 
     this.options.content = callerOptions; 

    // Otherwise assume they sent us a good options object 
    } else { 
     this.options = callerOptions; 
    } 

    _build(); 
    _contentLoaded(); 
}; 

Я хотел бы, чтобы иметь возможность использовать некоторые библиотеки я никогда не слышал, чтобы сделать что-то вроде этого:

// Maybe this is what it looks like with a method signature enforcement library 
lightbox = function (callerOptions) { 
    TheEnforcer(
    , { valid: [ 
       'string' // assumes that it is testing type against arguments by convention 
      , 'typeof([0].title) === "string" && typeof([0].content) === "string"' 
      ] 
     } 
    }); 

    // If they send us a string, assume it's the popup contents 
    if (typeof(callerOptions) === 'string') { 
     this.options = { 'content': callerOptions }; 

    // Otherwise we know they sent us a good options object 
    } else { 
     this.options = callerOptions; 
    } 

    _build(); 
    _contentLoaded(); 
}; 

Кто-нибудь когда-нибудь видел библиотеку Javascript, как это? Может быть, встроен в один из 1000 JS MV * Frameworks?

Edit: Похоже, этот является обычно заботятся мв * рамки. Backbone.js имеет как значения проверки, так и значения по умолчанию для его свойств модели. Я думаю, что они могут быть использованы для встречи или почти для того, чтобы встретиться с прецедентом, представленным здесь.

+3

Я не думаю, что вы должны пытаться заставить язык вести себя так, как он не был предназначен. Просто мое мнение. – bfavaretto

+0

Почему бы не создать «вспомогательный класс», который позаботится о данных, переданных в лайтбокс? Лайтбокс должен делать то, что он намерен делать, а не проверять параметры. Btw typeof используется без скобок. – Bakudan

+0

В скобках здесь делается вывод, что «TheEnforcer» использует массив аргументов в качестве объектов тестирования. Извините, что было неясно – SimplGy

ответ

0

Я думаю, что есть две части этого: философская/архитектурная и реализация.

С философской стороны, я думаю, нет ничего проще (для пользователей моего API, а не для меня, разработчика API), чем явные ожидания и сообщения об ошибках, которые описывают, что есть и не требуется для каждого метода.

На стороне реализации, о которой первоначально был задан вопрос, я думаю, что должен ответить сам. Модели Backbone.js, особенно часть .validate, похоже, очень хорошо справляются с этой потребностью. Мне еще нужно их использовать, но это единственное, что я нашел на данный момент.

http://documentcloud.github.com/backbone/#Model-validate

EDIT: Другим решением может быть время компиляции.Компилятор Google Closure, похоже, прекрасно справляется с этим: https://developers.google.com/closure/compiler/docs/js-for-compiler

2

(Это было intented комментарием, но он стал больше, чем ожидалось.)

Я понимаю, такая функция может быть полезна, но иногда я считаю, что следует по возможности избегать. И я думаю, что стандарт ECMA никогда не должен включать это.

Воспользуйтесь вашим примером: требуется заголовок и содержание лайтбокса. Зачем? Почему бы не отобразить пустой лайтбокс без заголовка или контента? На мой взгляд, это достойный запас. Если вы создаете API, тот, кто его использует, может проверять наличие пустого заголовка и содержимого и просто не вызывать функцию лайтбокса, если это необходимо. Кроме того, мне не нравится идея принудительного применения типов в JS.

Я думаю, что это радикально отличается от jQuery. Они просто предоставляют связанный объект оболочки (с кучей полезных методов внутри) и поддерживают определенный стиль кодирования/синтаксиса, и это большая часть jQuery. Это делает язык более простым, в отличие от подписи типа и метода - определенно не как «Simple As Could Be» (извините за это).