Typescript: Невозможно определить статическую функцию длины в классе

Я столкнулся с этим недавно. :(

Также некоторые другие запрещены, например, следующий код должен привести к ошибке (если мы сделаем эту функцию):

class C {
    static name = 'something';
    static arguments = 'args';
    static caller = 'caller';
}

console.log(C.name); // 'C'
console.log(C.arguments); // null
console.log(C.caller); // null

Однако не все из них являются стандартными.

Я не думаю, что свойства name , caller и length выполнимы. Они доступны только для чтения и не могут быть переопределены. Все присвоенные им назначения будут проигнорированы.

@tinganho согласился

Хорошо, но поскольку люди время от времени обнаруживают подобные ошибки, я думаю, что TS должен уведомлять их о том, что они делают что-то не так. Это потому, что такие свойства, как name или length , настолько естественны, чтобы их помнить, поэтому люди будут пытаться переопределять их снова и снова.

Может быть потому, что имя Ленг уже определено.

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

Пока вижу:
длина, имя, аргументы, вызывающий

Что именно должно произойти, если кто-то попытается присвоить статическому свойству одно из запрещенных имен? Ошибка компилятора? Видимое предупреждение пользователю?

Я новичок в этом, поэтому, если я что-то упускаю, я был бы признателен за некоторые рекомендации. : +1:

Почему бы не скомпилировать

class C {
    static name = 'something';
    static arguments = 'args';
    static caller = 'caller';
}

console.log(C.name); // 'C'
console.log(C.arguments); // null
console.log(C.caller); // null

к чему-то вроде

var C = (function () {
    function C() {
    }

    C.__statics = {
        name: 'something',
        arguments: 'args',
        caller: 'caller'
    };

    return C;
})();
console.log(C.__statics.name); // 'something'
console.log(C.__statics.arguments); // 'args'
console.log(C.__statics.caller); // 'caller'

Также возник вопрос о stackoverflow: http://stackoverflow.com/a/34644236/390330 : rose:

@zerkms, пожалуйста, не

Иногда нельзя произвольно переписывать имена в системе структурных типов.

Рассмотрим такой код

interface HasName {
  name: string;
}
class Foo {
  static name = 'fooClass';
}
let bar: HasName = { name: string };
let q = Math.random() > 0.5 ? Foo : bar;
console.log(q.name);

@RyanCavanaugh , это действительно

Если их невозможно перенести без риска, может, стоит их просто запретить?

Если их невозможно перенести без риска, может, стоит их просто запретить?

Точно не меняю транспайл, просто делаю ошибку компиляции: rose:

[...] может, стоит их просто запретить?

Какой-нибудь предприимчивый девелопер должен прислать нам пиар! :подмигивание:

Почему бы не использовать Object.defineProperty ?

например

class C {
    static length() { return "twelve"; }
}

будет переведено на что-то вроде

var C = (function () {
    function C() {
    }
    Object.defineProperty(C, "length", {
        value: function () { return "twelve"; },
        writable: true
    });
    return C;
}());

@ nicolo-ribaudo Это действительно работает. Мое мнение: но я бы предпочел ошибку такой транспиле. TypeScript обычно склоняется к изящной ошибке вместо исправления JavaScript_: rose:

TypeScript обычно склоняется к изящной ошибке вместо исправления JavaScript.

Разве не вся идея TS состоит в том, чтобы исправить JS, заполнив пробелы, которые он не может и никогда не сможет.

Разве не вся идея TS состоит в том, чтобы исправить JS, заполнив пробелы, которые он не может и никогда не сможет.

Да. Но понимая, как работает JavaScript. Возьмем, к примеру, null и undefined . TypeScript предпочитает понимать оба (вместо того, чтобы объединять его в одну вещь, как это делает Dart https://www.dartlang.org/docs/synonyms/). TypeScript выдает ошибки (вместо исправления в транспиле), если вы используете неправильный шаблон JavaScript: rose:

Мое мнение - мое собственное и не подтверждено никем, кроме меня: rose:

Между тем, встроенная поддержка ES6 / 2015 появилась в Chrome и Firefox. Если мы посмотрим, как они решают проблему изначально, то это будет близко к тому, что мы с @ nicolo-ribaudo предложили (см. № 9778).

Фрагмент для иллюстрации собственного поведения:

class Foo {
    constructor() {}
}
class Bar {
    static length() {}
    static name() {}
    static caller() {}
}
Foo.name = "FooChanged";
Bar.name = "Baz";

console.log(Foo.name) // Logs "Foo". Foo.name remains unwritable
console.log(Bar.name) // Logs "Baz".  Bar.name became writable

Что касается того, что @tinganho ранее писал о чтения name , length и caller мы можем наблюдать для собственных реализаций, что свойства доступны для записи в функции конструктора один раз мы определили любой из них как статический член класса (из-за этого не стесняйтесь просматривать или изменять мои недавние предупреждения в MDN относительно опасных предположений о Function.name для получения имени класса).

Таким образом, использование Object.defineProperty предложенное @ nicolo-ribaudo, точно имитирует собственное поведение. Следует учитывать, что в некоторых более старых, но совместимых с ES5 версиях браузеров для свойств задано значение configurable: false . Поэтому попытка сделать их writable: true для них не удастся (например, см. Возможность настройки Function.name )

Подводя итог, мой взгляд на проблему был следующим:

• Мы не можем использовать Object.defineProperty() для цели компиляции es3 . Однако без Object.defineProperty запуск кода ES3 в среде ES5 столкнулся бы с проблемой только для чтения. Поэтому нам нужна ошибка компиляции для цели es3
• скомпилируйте его с помощью Object.defineProperty() и writable: true для цели компиляции es5 и выдайте предупреждение / ошибку о том, что использование этих имен свойств может вызвать ошибки в браузерах x of version <= y предлагая что, если эти браузеры должны поддерживаться, самым безопасным вариантом было бы выбрать другое имя.
• если вы абсолютно не хотите, чтобы люди использовали свойства, сгенерируйте ошибку компиляции для любой цели.

Независимо от вывода компиляции, я думаю, что любое дополнительное сообщение было бы лучше, чем нынешняя ситуация (TS 1.8.10), когда мы не получаем никаких подсказок о потенциальных проблемах с выводом компилятора.

Изменить : добавлен фрагмент

@RyanCavanaugh : не могли бы вы еще раз вернуться к этому вопросу для вехи TS 2.0.1. Решение кажется простым, но в зависимости от того, какой вариант вы выберете, выход эмиттера может потребоваться изменить (см. Мой предыдущий комментарий). В таком случае, возможно, лучше будет включить исправление в выпуск TS 2.0.

Теги в PR указывают, что команда TypeScript, имеющая ограниченные ресурсы, оставляет это открытым для решения сообщества. Если вы хотите решить эту проблему, кто-то из более широкого сообщества должен будет заняться ею до тех пор, пока основная команда TypeScript не почувствует, что у них достаточно места в бэклоге, чтобы включить ее в выпуск (что, вероятно, займет много времени).

@kitsonk Спасибо, что объяснили этикетку PR. Думаю, я это понял. Я предложил еще раз оценить, является ли это правильным способом решения проблемы. Свойства статического класса, называемые _name_ или _length_, не так маловероятны, и TS выдает для этого ошибочный вывод. Следовательно, я бы даже не называл проблему «крайним случаем».

Я считаю, что статические свойства лежат в основе языка, и даже если еще нет запросов на вытягивание, решения проблемы были представлены в этом потоке.

Тем не менее, я оценю, смогу ли я предоставить PR, но должен признать, что я еще не настолько хорошо осведомлен об источниках TS и боюсь, что TS 2.0 будет выпущен раньше.