Decorators offer a convenient declarative syntax to modify the shape of class declarations. This capability can be used for myriad purposes including modifying the descriptor of the declared member (@nonconfigurable/@enumerable), adding metadata (as used by Angular), and more.
As of this proposal, decorators can be attached to either classes or class members. An example of such a class might be:
Prior to the class
keyword and prior to method definitions are a new @
followed by a sequence of dotted identifiers (no []
access is allowed due to grammar difficulties) and an argument list. Thus, @foo.bar()
is valid, while @foo().bar()
(and @foo[bar]
) are syntax errors.
The syntax here can be pretty much anything, but this proposal takes a maximally conservative approach. Square brackets can be made unambiguous with a clever cover grammar but the syntax is confusing and error-prone.
Elements of the
A member decorator function is a function which takes a member descriptor and which returns a member descriptor. A member descriptor is similar to a property descriptor and has the following shape:
interface MemberDesciptor {
kind: "Property"
key: string,
isStatic: boolean,
descriptor: PropertyDescriptor,
extras?: MemberDescriptor[]
finisher?: (klass): void;
}
A class decorator function is a function which takes a constructor, heritage (parent class), and an array of MemberDescriptors that represent the instance and static members of the class.
There are a number of examples of real-world usage based on previous drafts of this proposal.
Several frameworks have also adopted decorators in various forms.
With parameters object and optional parameter functionPrototype.
With parameter className.
constructor(... args){ super (...args);}
using the syntactic grammar with the constructor( ){ }
using the syntactic grammar with the "derived"
."constructor"
, F)."property"
, [[Static]]: static, [[Key]]: descriptor.[[Key]], [[Descriptor]]: descriptor.[[Descriptor]], [[Decorators]]: decorators}."derived"
."constructor"
, constructor)."property"
We need to make a decision about what validations we need on the extras list, and when to apply it.
At minimum, if one decorator marks a property as non-configurable, another decorator will not be allowed to modify it.
There are several options:
We would prefer to avoid the first option, because it is useful for users of decorators to know if they have caused a name conflict.
Note: The second and third option are observably different in terms of timing.
In terms of validations, we would prefer to disallow naming conflicts caused by extras, which would otherwise become confusing silent errors.
We would also prefer to disallow, as a validation rule, a property made non-configurable by one decorator to be modified by a future one (rather than causing it to fail at application time).
It seems important to allow decorators on a single element to be reordered flexibly, so that for example a @nonconfigurable
decorator could be applied before or after an @enumerable
decorator. On the other hand, decorators on separate elements that end up affecting class properties of the same name are almost always going to be bugs (analogous to name collisions arising from unhygienic macros). For both of these reasons, it seems important for a single element's decorators to be combined permissively, whereas the extras produced by distinct elements should be validated not to have conflicts.
With parameters object and enumerable.
"get"
)."set"
)."prototype"
, PropertyDescriptor{[[Value]]: prototype, [[Writable]]: With parameter function.
The semantics of functions leaked to JavaScript during decoration was contentious in Munich. The exact semantics will be driven by implementation considerations.
With parameter function.
The semantics of functions leaked to JavaScript during decoration was contentious in Munich. The exact semantics will be driven by implementation considerations.
With parameter function.
The semantics of functions leaked to JavaScript during decoration was contentious in Munich. The exact semantics will be driven by implementation considerations.
With parameter elements.
The semantics of functions leaked to JavaScript during decoration was contentious in Munich. The exact semantics will be driven by implementation considerations.
With parameter element.
"property"
."extras"
).Future versions of the spec will create element descriptors with other [[Kind]]s.
There is a decision-point about what validation rules should be applied to the merging that happens right before merging.
With parameters decorators, constructor, heritage and elementDescriptors.
"constructor"
)."elements"
).There is a decision-point about what validation rules should be applied to the merging.
We also need to decide whether to produce an error if the returned constructor from a decorator has the wrong prototype. We think it should be an error.
With parameter element.
"kind"
, element.[[Kind]])."isStatic"
, element.[[Static]])."key"
, element.[[Key]])."descriptor"
, ! With parameter descriptor.
"kind"
)."property"
, throw a TypeError exception."isStatic"
))."key"
))."descriptor"
)).Todo: Should probably add validations for having kind, static, and key fields.
© 2017 Yehuda Katz, Brian Terlson, Ecma International
All Software contained in this document ("Software") is protected by copyright and is being made available under the "BSD License", included below. This Software may be subject to third party rights (rights from parties other than Ecma International), including patent rights, and no licenses under such third party rights are granted under this license even if the third party concerned is a member of Ecma International. SEE THE ECMA CODE OF CONDUCT IN PATENT MATTERS AVAILABLE AT http://www.ecma-international.org/memento/codeofconduct.htm FOR INFORMATION REGARDING THE LICENSING OF PATENT CLAIMS THAT ARE REQUIRED TO IMPLEMENT ECMA INTERNATIONAL STANDARDS.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
THIS SOFTWARE IS PROVIDED BY THE ECMA INTERNATIONAL "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL ECMA INTERNATIONAL BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.