Re: Decorators for functions

Andreas, thanks for correcting me on the optimization angle. I've been under that impression for awhile. Are you saying that to achieve the optimization I envision, we'd need declarative syntax for descriptor properties (like enumerability etc), rather than function calls? or would that also

Re: Decorators for functions

OK, appreciate that. Let's explore this problem space: Why not have syntax to set a property descriptor onto a class or object literal? In Python, this is implicit. For example (IIRC): ```python class Foo: prop = some_descriptor x = 100 ``` Both `Foo.x` and `Foo().x` (instance attribute

Re: Decorators for functions

Agred with Jordan and it's basically what I've said since the beginning. Decorators with target and descriptors are fine and works well, you drop targets and descriptors from the equation, it's an ugly mess that canno be ported and every decorator will magically decide if it should work with a

Re: Calling toString on function proxy throws TypeError exception

I know that's true in general. But we made a few exceptions, especially for functions and arrays. I thought F.p.toString was one, but maybe not. I just don't remember. On Thu, Oct 22, 2015 at 2:36 PM, Allen Wirfs-Brock wrote: > > On Oct 22, 2015, at 11:23 AM, Mark S.

Re: Calling toString on function proxy throws TypeError exception

> On Oct 22, 2015, at 11:43 AM, Mark S. Miller wrote: > > I know that's true in general. But we made a few exceptions, especially for > functions and arrays. I thought F.p.toString was one, but maybe not. I just > don't remember. There are no such special cases that I’m

Re: Decorators for functions

I don't think > ```@@ or @() or @::meomize``` would really help much, you can tell what the decorator does by simply looking at its name. And looks like you can not use @ and @@ for the same decorator function without adding extra condition checking inside the function. There are two patterns

RE: Calling toString on function proxy throws TypeError exception

Proxies without handlers are not indistinguishable from their targets. There are many examples, eg. `let p = new Proxy(new Map(), {}); p.set(1, 1);` also throws. From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Thomas Greiner Sent: Thursday, October 22, 2015 4:39 AM To:

Re: Decorators for functions

Ron, there's **no way** you can distinguish a class from a generic function in current specifications. Having one argument won't tell me much, having a way to know that is not a class I need to decorate (traits/mixins) but just a function, so ignoring its prototype and do something else, would

Re: Decorators for functions

Removing ambiguity is my point since the very first post: current proposal is about a target, a property name, and a descriptor for such property ... having functions/variables decorators have no target (in strict mode undefined can't be a target, right?) and not necessarily a descriptor, or if

RE: Decorators for functions

Andrea, Is your concern about disambiguating the usage of a decorator at the call site or within the body of the decorator? In the current proposal, you can decorate a class member, or the class itself. When decorating a class member, three arguments are passed to the decorator: The target,

Re: Calling toString on function proxy throws TypeError exception

> On Oct 22, 2015, at 11:23 AM, Mark S. Miller wrote: > > Tom, this doesn't sound right to me. Didn't we intend > Function.prototype.toString to be transparent thru function proxies? > > cc'ing Allen and Brian > There is nothing unique to `toString` going on there. This

Re: Calling toString on function proxy throws TypeError exception

Ok, that all makes sense and is fine with me. Thanks for clarifying. Tom, I'm still curious what you remember? On Thu, Oct 22, 2015 at 2:59 PM, Allen Wirfs-Brock wrote: > > On Oct 22, 2015, at 11:43 AM, Mark S. Miller wrote: > > I know that's true

Re: Decorators for functions

On 22 October 2015 at 06:34, Jordan Harband wrote: > One thing that seems to be missing from this thread is acknowledgement that > decorators are not just simple function wrappers. They take a property > descriptor as an argument, and they can return a new property descriptor -

Calling toString on function proxy throws TypeError exception

According to https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/toString `Function.prototype.toString` is supposed to throw a `TypeError` exception when used on a function proxy. That's also consistent with how it's defined at

Re: Decorators for functions

Hi people. After reading the conversation, I think there is no ambiguity at all or, may be, it must be there: decorating a function should be like decorating a class, you can not distinguish between them and that's all. Just look at the code generated in Babel:

Re: Decorators for functions

which one is true? > I think there is no ambiguity at all ... decorating a function should be like decorating a class 'cause I think those are very different things. You gonna wrap for sure the first one, you most likely ever even bother replacing the class, rather enriching its prototype or its

Re: Any reason template string with empty interpolation placeholder (`${}`) throws?

Doesn't necessarily seem like a bad idea. I could be on board with that. > On Oct 22, 2015, at 6:18 PM, Mohsen Azimi wrote: > > Pardon my lack of use of proper terminology. > > This is kind of annoying working with large template strings. When I leave an > interpolation

RE: Decorators for functions

> -Original Message- > From: Andrea Giammarchi [mailto:andrea.giammar...@gmail.com] > Sent: Thursday, October 22, 2015 12:53 PM > Ron, there's **no way** you can distinguish a class from a generic function > in current specifications. Yes, this is true. However, decorators aren't in the

Re: Decorators for functions

It's all OK to discuss this for the future, meanwhile there won't be a way to tell older engines the difference, which is the portability concern I've been talking about. I guess thought it would be very misleading to have decorators that accepts both classes and regular functions, so maybe the

Any reason template string with empty interpolation placeholder (`${}`) throws?

Pardon my lack of use of proper terminology. This is kind of annoying working with large template strings. When I leave an interpolation placeholder(what's the right name?) empty it blows up all my code. Can it be forgiving like Ruby and CoffeScript and just replace it with empty string?

Re: Re: Decorators for functions

Andrea, My point wasn’t to implement something that allows the decorator function to figure out the difference between class and function. The point is to be able to show the difference in your code, so that it can tell the developer what the code is doing. Also, the [‘ambient decorator’

Re: Calling toString on function proxy throws TypeError exception

2015-10-22 21:03 GMT+02:00 Mark Miller : > Ok, that all makes sense and is fine with me. Thanks for clarifying. > > Tom, I'm still curious what you remember? > What I remember is that the original direct proxies spec did the transparent forwarding. wiki.ecmascript.org still

Re: Calling toString on function proxy throws TypeError exception

> On Oct 22, 2015, at 1:38 PM, Tom Van Cutsem wrote: > > ... > I cannot recall any specific discussions on why that behavior was changed to > throwing a TypeError instead. The only reason I can come up with is that it > could be deemed a violation of the proxy's

Re: Any reason template string with empty interpolation placeholder (`${}`) throws?

On Thu, Oct 22, 2015 at 8:54 PM, Caitlin Potter wrote: > > JavaScript does not have string interpolation. It has arbitrary value > interpolation. > > Disagree. `foo ${bar} baz` is string interpolation. `${bar}` becomes > `ToString(bar)`. Tagged templates were an addition

Re: Any reason template string with empty interpolation placeholder (`${}`) throws?

I’m not making a claim about history, I wasn’t in the room when they were presented. It’s a claim about creating something that was never really needed by the vast majority of users. It’s nice to have, but it’s not the most useful aspect of template literals/quasi literals. It makes the spec

Re: Re: Decorators for functions

I think I am quite off topic, how about this solution: If we restrict only use decorator on class And use ```@annotation@``` decorator that absolutely does not alter the code behavior for functions, for the ambient case?___ es-discuss mailing list

Re: Any reason template string with empty interpolation placeholder (`${}`) throws?

Cute, but nobody is realistically going to do that. Possible valid uses for the empty placeholder: - Contents of expression commented out, maybe debugging if it causes side effects which may be harmful - Expression is a placeholder, with contents soon to come (mentioned by OP) The DSL thing is

Re: Any reason template string with empty interpolation placeholder (`${}`) throws?

On Thu, Oct 22, 2015 at 7:20 PM, Caitlin Potter wrote: > Cute, but nobody is realistically going to do that. > Since `${}` is a static error, what do you realistically think people will do? Especially if they meant `${''}`, how do you expect them to react to the static

Re: Any reason template string with empty interpolation placeholder (`${}`) throws?

JavaScript does not have string interpolation. It has arbitrary value interpolation. On Thu, Oct 22, 2015 at 8:34 PM, Caitlin Potter wrote: > Okay, but usability wise, this kind of sucks. There's a reason it's not > what people expect, and why other languages with

Re: Any reason template string with empty interpolation placeholder (`${}`) throws?

The history does not matter. It doesn’t make a difference what someone presented or argued for to a room full of people. What matters is how they’re actually used in practice. There are some libraries which do some clever things with them. They are not common, there are not a lot of them, and

RE: Any reason template string with empty interpolation placeholder (`${}`) throws?

If there were to be a value for `${}`, `undefined` makes more sense to me than the empty string as a default “nothing” value. From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Caitlin Potter Sent: Thursday, October 22, 2015 19:20 To: Mark S. Miller Cc:

Re: Any reason template string with empty interpolation placeholder (`${}`) throws?

Okay, but usability wise, this kind of sucks. There's a reason it's not what people expect, and why other languages with string interpolation behave differently. > On Oct 22, 2015, at 8:24 PM, Allen Wirfs-Brock > wrote: > > >> On Oct 22, 2015, at 4:55 PM, Mark

Re: Any reason template string with empty interpolation placeholder (`${}`) throws?

(oops, sent from wrong account) > On Oct 22, 2015, at 4:55 PM, Mark Miller > wrote: > > > > On Thu, Oct 22, 2015 at 7:20 PM, Caitlin Potter > wrote: > Cute, but nobody is realistically

Re: Any reason template string with empty interpolation placeholder (`${}`) throws?

> JavaScript does not have string interpolation. It has arbitrary value > interpolation. Disagree. `foo ${bar} baz` is string interpolation. `${bar}` becomes `ToString(bar)`. Tagged templates were an addition that weren’t really needed. Since they exist, great, people can come up with some

Re: Any reason template string with empty interpolation placeholder (`${}`) throws?

On Thu, Oct 22, 2015 at 8:58 PM, Caitlin Potter wrote: > The history does not matter. > Excuse me. "Tagged templates were an addition" sounded like a claim about history. > It doesn’t make a difference what someone presented or argued for to a > room full of people.

Re: Decorators for functions

I think the main debate here is ergonomics. And by the way, since most descriptors simply replace the `value` property (especially most that are generic functional utilities), it could just as easily be made to deal with both. I already make most of my descriptors that way now, so they can be

RE: Decorators for functions

On Thu Oct 22 07:44 AM, Andreas Rossberg wrote: > > determined at creation time, allowing for massive engine optimization, > Ya I'm not sure from which hat "massive engine optimization" comes from? What's meant is likely using decorators as annotations (compile time optimizations hints):