different angle on functions decorators: classes should not be decoratable

[saurik]

So, I've read through the issues asking for functions to support being decorated, and I have a different take: I don't think classes should support decorators, which also solves that semantic divide. The only reason to have decorator syntax at all is because of the limitations of object property syntax with respect to being able to alter the value separate from the name and being able to modify the descriptor. This is why the meat of decorators take three arguments: the target, the name, and the descriptor.

I can totally appreciate why developers would feel the need to have this syntax for these cases. I see @nonenumerable and I'm like "wow, yeah!! I'd love to be able to have that, instead of sitting around with the full verbosity of Object.defineProperty". Or being able to alter a function and turn it into a getter and setter: that also adds real power that I didn't have before without pretty painful workarounds where I stop using anything remotely straightforward and refactor to use Object.defineProperty.

However, for both bare functions and classes, there is very almost no difference from just calling the "decorator" directly on the value. The reason that we need this syntax in Python is because the way indentation kills the ability for that language to have anonymous functions, an issue JavaScript does not have. Meanwhile, attempting to support both class decorators and method decorators leads to two forms of decorators with different arguments and different semantics, which just seems strange.

Further, supporting decorators for classes begs the question of supporting them on functions, and in addition to opening the Pandora's Box of function hoisting scope, one realizes that it further emphasizes the semantic difference between the two different kinds of decorators: the various decorators in the draft specification for this feature all sound reasonable to also use with bare functions, but they all assume that there is a target object and a descriptor involved, which isn't often the case with functions.

(And, if we want to compare to Python for a second, we will see that while it supports decorators on various kinds of things, including functions and classes, in all cases the decorator has the same semantics: it returns a function that takes a single value argument and returns a replacement value that will be used for the binding. All of the "meta" information about class members is stored on the member, not in a descriptor of the class, so there is no semantics split between the use cases.)

I thereby will argue that this feature should be postponed for classes (as again: it is effectively the same syntax to just call the decorator passing the class as an argument, it will make people stop asking for this feature to be implemented on bare functions, and, and I really think this is important, it means that there is only a single semantics for what arguments a decorator takes: a decorator fundamentally acts on a target, name, and descriptor) but implemented for members (where it seems valuable).

(BTW: the people who are arguing that people will create degenerate classes in order to get access to decorators, to me, are actually helping provide an argument for this, as they are failing to notice that the different semantics for decorators means that a lot of the decorators people will want to define will only work for class/object members and won't work for bare functions as there will not be any descriptor to modify; a lot of these use cases for decorators, not just the syntax, actually require an object.)

(I constructed this as a separate issue because it is asking for the exact opposite result from the other issues talking about this overall concept. I'm terribly sorry if someone fundamentally disagrees that this is the correct approach to organizing these conversations. FWIW, without threads, I'd think that having this idea in the same issue as the opposite idea would probably make it fundamentally more confusing and, if nothing else, clutter the conversation of people talking about how to support bare functions.)

[kobezzza]

👎

[loganfsmyth]

@kobezzza Any constructive feedback to offer?

@saurik I'm with you. I get the argument for them, and I can see them potentially being useful as a declarative mechanism, but it is also important that the syntax be consistent, and it seems totally reasonable to me to limit the discussion to only descriptor-level decoration for now so that it's possible to reach a clear consensus on the proposal. I'll be curious to hear what others think. I'd be very in favor of leaving statement-level decoration for the future.

[kobezzza]

@kobezzza Any constructive feedback to offer?

Angular2, Iridium and other amazing projects uses class decorators and it's real powerfull and sugar feature. Do you want to kill it?

[arshtepe]

@kobezzza is right, decorators it is powerful tools in ja

[loganfsmyth]

The question for this specific case is, is

@dec
class Foo {}

so much more powerful than

let Foo = dec(class {});

that it would prompt rushing to add inconsistency to the language. No-one is arguing that they aren't powerful. My motivation for siding with this is entirely that it's not clear how it could be added consistently with everything else. If it can be done in a consistent way that won't lead to confusion, I'm all for it, but I'm not convinced that is the case.

"People are using it" is a useful metric for making decisions, but it is not the only thing that should drive the addition of something into a language. There is nothing provided by class decorators that you can't already get without them, whereas that is not the case with method decorators, which is why they are cool.

[silkentrance]

I do not see a problem in having both free function decorators and class decorators work exactly the same way, e.g.

@decorate
function foo()
{...}

const a = @decorate function () {...}

vs

@decorate
class Foo {}

While I can see that from the context alone the decorator cannot decide whether it is decorating a class or a free function, additional information needs to be passed to the decorator, e.g. {isclass:boolean} as the last parameter.
And that information can be gathered during compile time.

Of course, one can still declare standard functions as classes, e.g.

function FooError()
{...}

FooError.prototype = new Error();
Object.setPrototypeOf(FooError, Error);

Yet, I do not see any problem here as the developer who uses these idioms will know that this is a class rather than a free function.

And I also do not see why one cannot simply have both notations, as it is perfectly fine with Python, provided of course, that the @ notation will also be made available for free functions, e.g.

@decorate
function foo() {}

const foo = decorate(function () {});

const bar = decorate(class {});

The latter two, however, are indeed more complicated as decorate() could also expect a callback, and return any value or none at all.

While the last example could be solved by the compiler using some kind of back tracking and traversing the AST upwards, the decorated function will go unnoticed by the compiler.

Yet, I do not see any problem here. And the same is true for Python. The syntactic sugar of having @decorate will be resolved by injecting a call to the decorator in the AST. As for the direct use of the decorator, the user will already provide for that call and the compiler will have no need of knowing whether the function gets decorated or not.

[loganfsmyth]

@silkentrance Supporting decorators on function declarations has been discussed tons in #4 I'd suggest starting there to understand the concerns around supporting them. Essentially it comes down to hoisting being problematic though.

[silkentrance]

@loganfsmyth sure there are a lot of things involved, yet I wanted to shed some light as the issue whether class decorators are useful or more powerful than by decorating a class in the way of

const Foo = decorate(
class Foo
{
...
});

and why that notion would even be considered at all. Looking at the above code I would just say no and stick to class decorators as they are and not question their existence.

Instead, focus should lie on whether it is desirable to not have the same feature for free functions as well, and of course, always also allowing the user to call decorators directly.

In Python the co-existence of both approaches has worked very well.

[loganfsmyth]

I was primarily responding to

And I also do not see why one cannot simply have both notations, as it is perfectly fine with Python

We can potentially have both, but function declaration hoisting makes the behavior of decorated function declarations potentially unexpected and complex.

The question is then, if we don't have it on functions, is it worth having on classes, and then needing to have a potentially unexpected difference in syntax.

The latter two, however, are indeed more complicated as decorate() could also expect a callback, and return any value or none at all.

Yes, you'd need to understand the function signature when calling the function, rather than relying on it to be called automatically for you, but that's already something all developers are already accustomed to, for the callback portion, and return any value or none at all also applies to the decorator case, so it doesn't seem to really point toward one option or the other.

[silkentrance]

@loganfsmyth In my project, https://github.com/coldrye-es/inxs-common, and https://github.com/coldrye-es/inxs, I refrained myself and also users of that framework from using class/constructor decorators. The reasoning here being that one is not able to replace the constructor function, at least, I did not see any way to make this possible, given the current implementation of the decorator transformer, legacy or not.

But, and since I am working on this in my early/late night spare time, I might be overlooking something in the generated code.

However, with some indirection provided by babel I might be able to support class/constructor decorators. The main purpose of such constructors then being to (a) inject parameters into the constructor and to (b) enhance the class and (c) altogether override its declaration.

Considering (c) this would allow us to have Meta Types, e.g. the decorators would handle the Meta Type and then will return an enhanced/accommodated version of that class, or target when talking decorators.

[silkentrance]

@loganfsmyth As for function hoisting, I do not remember Javascript for doing that for a long time. Instead I remember it to have functions declared before they are being used, lacking the prototypes that for example C or C++ offers. As such I do believe that the decision made towards introducing function hoisting was a bad one. Yet this is not to be discussed here.

[loganfsmyth]

Yeah, hoisting has its uses but it does make this difficult.

The reasoning here being that one is not able to replace the constructor function, at least, I did not see any way to make this possible

You can in fact. Just as a method decorator can mutate the descriptor passed in or return a new descriptor, class decorators can mutate the constructor passed in or return an entirely new constructor, e.g.

function replaceWith(otherConstructor){
  return function(target){
    return otherConstructor;
  }
}

class Foo {

}

@replaceWith(Foo)
class Bar {

}

console.log(Foo.name);
console.log(Bar.name);

will print Foo twice.

[silkentrance]

@loganfsmyth so class decorators ftw?

And thanks for pointing this one out, as I was unable to find this one out by myself.

[saurik]

@loganfsmyth That did not replace the constructor in the same way I think (though maybe I am wrong) @silkentrance meant: it replaced the "entire class" (which I put in quotes, as there is now a terminology clash from having added class syntax to JavaScript).

@silkentrance On "so class decorators ftw", that is of course identical to `var Bar = replaceWith(Foo)(class {});": the class decorator here is adding only the minimal possible syntax sugar, and is doing it with semantics that are different from method decorators.

I am someone who programs (often sadly) a lot in Python 2. And I use decorators a lot ;P. I have been known to teach classes where I just go into advanced usages of decorators. I layer decorators on decorators and even use them to provide something similar to Ruby block syntax.

I have, on many occasions, used decorators in ways that are barely defensible. In fact, I'm started putting together examples of how I've been using decorators to put into this comment (to show the crazy corner cases), and it started to become kind of embarrassing ;P.

The reason this pattern is so compelling in Python is because "everything is the same".

1. The syntax for calling a class constructor and calling a function is identical: there is no "new" syntax to change the call site into a regime that ignores the return value, allowing you to override the construction of a class no differently than you would any other function.

2. There is no storage difference (such as "is it on the constructor or on the prototype of the constructor") between static and instance methods: they are all just stored on the class itself. You can therefore call static methods on instance objects: the self binding is ignored.

3. Python does not have an implicit this, so all arguments to all functions (including the constructor!) are explicit. This means that slicing, forwarding, and binding arguments works exactly the same whether you are talking about a static method, instance method, or the class itself.

The result of this is that if you implement a naive version of memoize, it "just works". It always "just works". I will actually say it is epic just how well it "just works" in every situation. Here is a demo of memoizing, in Python, all of a function, a class, an instance method, and a static method.

import pickle

def memoize(storage, prefix):
    def wrapped(method):
        def replaced(*args, **kw):
            key = prefix + ":" + pickle.dumps((args, kw))
            if key in storage:
                print "cached!", prefix, ','.join(str(arg) for arg in args)
                return storage[key]
            value = method(*args, **kw)
            storage[key] = value
            return value
        return replaced
    return wrapped

store = {}

@memoize(store, "function")
def fib(value):
    if value < 2:
        return 1
    return fib(value - 1) + fib(value - 2)

@memoize(store, "class")
class Test:
    def __init__(self, value):
        self.value = value

    @memoize(store, "instance")
    def add(self, inc):
        return self.value + inc

    @staticmethod
    @memoize(store, "static")
    def wow(thing):
        return thing * 10

    def __str__(self):
        return "Test=" + str(self.value)

print fib(5)
print Test(0)
bob = Test(5)
print bob
print bob.add(10)
print bob.wow(20)

print
print "ROUND 2"
print

print fib(5)
print Test(0)
fred = Test(5)
print fred
print fred.add(10)
print fred.wow(20)

print
for item in sorted(store.items()):
    print item

$ python test.py
cached! function 1
cached! function 2
cached! function 3
8
Test=0
Test=5
15
200

ROUND 2

cached! function 5
8
cached! class 0
Test=0
cached! class 5
Test=5
cached! instance Test=5,10
15
cached! static 20
200

('class:((I0\ntp1\n(dp2\nt.', <__main__.Test instance at 0x107bac5a8>)
('class:((I5\ntp1\n(dp2\nt.', <__main__.Test instance at 0x107bac5f0>)
('function:((I0\ntp1\n(dp2\nt.', 1)
('function:((I1\ntp1\n(dp2\nt.', 1)
('function:((I2\ntp1\n(dp2\nt.', 2)
('function:((I3\ntp1\n(dp2\nt.', 3)
('function:((I4\ntp1\n(dp2\nt.', 5)
('function:((I5\ntp1\n(dp2\nt.', 8)
("instance:(((i__main__\nTest\np1\n(dp2\nS'value'\np3\nI5\nsbI10\ntp4\n(dp5\nt.", 15)
('static:((I20\ntp1\n(dp2\nt.', 200)

Yes: I'm seriously memoizing the add instance method there without caring that self is an argument, and that's correct behavior as the return result of an instance method will depend on the value of that object (which I'm obtaining in this case using pickle, so as to memoize to memcached.)

(In case anyone reads this and questions the general applicability of this because I happened to use pickle to get a class "value", I could have alternatively implemented a custom comparator on Test: then I could have stored list(args) + kw.items() as the key and it would also work.)

(Also, I actually did end up getting burned by pickle on this thought process: after posting this I decided to go back and add some new functionality to this memoize implementation, which would save a pickled copy of the object, making this really work with memcached, and that ended up requiring me to add a default =0 initializer to __init__ as unpickle special cases class constructors, to avoid calling them, in a way that detects my decorator, and in the end was simply unworkable :/. The issue essentially comes down to pickle not being prepared for the case where a class gets replaced in some crazy way.)

The result of trying to wedge this syntax into JavaScript simply doesn't have this level of beauty. Python just so happened to be designed in a way where this ended up making sense: there is no "static" keyword, instead @staticmethod modifies a function to ignore a self binding ;P.

class Bob:
    def __init__(self, value):
        self.value = value

@staticmethod
def one(value):
    return value + 1
print one

def two(self):
    return self.value + 2
print two

Bob.one = one
Bob.two = two

bob = Bob(10)
print bob.one(20)
print bob.two()

<staticmethod object at 0x108c1d6a8>
<function two at 0x108c0aa28>
21
12

Yes: I can use @staticmethod there ;P. This is why decorators can be so pervasive in Python: because the language happened to have been designed in a way that made everything operate in a homogenous manner that leads itself to a "eureka" moment of "I can abstract this pattern".

(You can actually use @staticmethod on a class, and the result works: you get back a "staticmethod" wrapper object that works. However, member access has some frustrating special case for functions to do the self bind, so this doesn't actually change the behavior. This is the only thing I've been able to think of that really causes the symmetry to break, and it is something I've only tried because I spent enough time programming in Java to wonder if I could implement an "inner class". FWIW, though, this is fixable by just wrapping the class in a function, which works because of all the stuff already said ;P.)

JavaScript, in comparison, is a mish-mash of different semantics. But thankfully, JavaScript also just doesn't need them in all these cases, given that JavaScript has good support for anonymous functions, and even decided to maintain that tradition by supporting anonymous classes.

But trying to wedge in the various forms of decorators, without the underlying "wow, this is all the same" that Python has, leads to a fractured set of decorators that not only are slightly incompatible in where they can be used, but actually take different numbers of arguments ;P.

I do think the concept adds a lot of value to the method examples, as there is otherwise no way to modify the descriptor, and being able to replace functions with getter and setter pairs is an interesting use case (though #2 :/). But class decorators do not, to me, seem to be a positive addition.

[silkentrance]

@saurik thanks for the exhaustive example on how decorators should not be used and Python lacking proper sanity checks in the built in decorators 😀.

However, and for the sheer bang of syntactic sugar, I still do believe that class decorators are a valid option over first declaring a class and then replacing its declaration with a decorated version of it, e.g.

class __Foo {}
let _Foo = mixin(iface1, iface2)(__Foo);
_Foo = registerimpl(__Foo);
export const Foo = _Foo;

vs

@registerimpl
@mixin(iface1, iface2)
class Foo {}

The latter is much more easier to read and author while the first will have the developer thinking of how to make this work and introduce additional code that can well be generated by the transpiler.
And the additional benefit here is that class Foo keeps its identity and is not now suddenly known as __Foo or that you have a class Foo declaration and then override it by exporting a const Foo = _Foo.

To sum it up, not having the class decorators will likely make the code more unreadable and less understandable.

And, given the nature of class decorators, a developer is free to choose between the two approaches based on personal preference. But I strongly believe, that most would opt for the @ instead of the direct call approach.

And, actually, in my framework I provide the user with the @inject decorator while internally, the injector is actually a class that will be called to perform the actual injection. So here you have both worlds combined, the framework using the direct call approach and the user being left with the option of using the @inject decorator.

And this is what decorators are made for, providing a simple API to from the most simple to the most complex of frameworks.

Of course, as I mentioned before, I currently do not support class decorators due to my lack of knowledge on the inner workings of the transpiler. But thanks to @loganfsmyth I am now able to implement these as well.