Luke Scott

Impossible? No. The parser knows what context the decorator is being used. It can easily call a different method depending on the context.

The original use-case of using the same decorator in both class and method context may not be the best approach. However, the current implementing does not stop someone from trying...

I would agree that the decorator definition is very inconsistent, whether it be between classes and methods, or `@decorator` vs `@decorator()`. There is just too much variation here. Having to...

@kobezzza Ah. That is probably the biggest use case. Seems a bit odd they chose to do components like that. React does `class TodoApp extends Component {}`. I currently use...

Using get / set makes the initialization of the variable lazy. It really isn't much different than the current initializer, besides the initializer is always run in the constructor. I...

@ljharb Perhaps I'm missing something, but `explicitNull` requires null. In my case I disallow null and allow undefined only when not required. Currently prop-types allows null or undefined when not...

@ljharb This was the best stand-alone work-around I could come up with: ```js // Usage: notNull(PropType.string) if (process.env.NODE_ENV !== "production") { var secret = require("prop-types/lib/ReactPropTypesSecret") } function notNull(validator) { if...

Is there any reason to not require the outer function to always return a decorator function as the OP suggests? It would make things far simpler.

Complicate the language? Checking arguments.length is complex. Expecting `@myDecorator` and `@myDecorator()` to "do the same thing" seems reasonable to me. Why is the decorator syntax like this? ``` javascript function...

Awesome, thank you! I do prefer to keep the delegate the same. If you inherit from UIScrollView delegate as issue #7 suggests, it should fix the problem mentioned in that...