Method Combinators in CoffeeScript(github.com) |
Method Combinators in CoffeeScript(github.com) |
The key is to remember that, in JavaScript, you aren't really "defining instance methods" in the way you are in almost any other language. You're just passing anonymous functions as the value tied to some key in a dictionary, which happens to be the prototype of some set of objects. Once you get that into your mind and let it play around for a bit, you realize that you could be getting the anonymous function from anywhere!
From a function-factory, that takes some arguments and returns a function:
render: renderWithTemplate("some_template")
onScroll: _.debounce(100, function(){ /* do something */ })
viewInstance.onScroll = _.bind(somethingElse.render, somethingElse);
> viewInstance.onScroll = somethingElse.render;
This one is a bit dangerous, because as you mention the "methods" are just anonymous functions assigned to objects. If `render` is expecting to be called on a `somethingElse`, this might not work right without being bound.
> Our decorators work just like Python method decorators, only we don't need any magic syntax for them because CoffeeScript, like JavaScript, already has this idea that functions can return functions and there's nothing particularly magic about defining a method, it's just an expression that evaluates to a function.
Python also has this idea (called ‘higher-order functions’). The difference is in syntax—function calls require parens in Python, and anonymous functions aren't that well supported. Therefore the need for special syntax construct to make decorator use convenient.
Neither does Python, at definition time. All the difference is in the processing performed by the class constructor (`type`) when the class object is created. Before that, it's a bog-standard function.
> which is what allows you to use first-class functional combinators as decorators.
Which is exactly like Python, the original decorators[0][1] predate the syntactic extension by several versions, the original syntax for applying them was:
def some_method(cls):
pass
some_method = classmethod(some_method)
[0] http://docs.python.org/library/functions.html?highlight=clas...
[1] http://docs.python.org/library/functions.html?highlight=clas...
Python decorators are a hack around the lack of proper lambda ;) Just pass the function: decorate -> … Where "decorate" is a fn
There's no point in having an anonymous function decorator. You'd simply inline it into the body itself right on the spot, anything else would simply be obfuscation for the sake of obfuscation. This only makes sense if you're using a decorator applied elsewhere, at which point all languages require you to have named it, so there's no point complaining about lack of anonymous functions here.
Python has first-class functions. It even has first-class methods, with automatic instance binding. It just doesn't quite work how very functionally-oriented people want it to work. Part of the reason I don't like the kvetching that such people do is that it does seem to convince people that Python is lacking function references. Nope. It just doesn't spell them to everybody's taste (for instance, "it doesn't have Ruby blocks" translates to "it doesn't have block syntax", not "it can't do function references", and this is a taste issue not a fundamental capability issue), and the can rarely have moderately inconvenient scope rules if you want to write to outer scopes.
Decorators are syntax sugar, not a new feature.
https://en.wikipedia.org/wiki/Python_syntax_and_semantics#Fi...
What I was speaking to is the desire to write:
class SomeExampleModel:
def setHeavyweightProperty:
triggers('cache:dirty')(
lambda self, property, value:
...something...
I'm open to reëducation.
ifAuthorized("admin", lambda x:
// more code hereTechnically, Python's lambdas are one-expression not one-line.
Within that constraint you can create as complex lambdas as you want (you'll probably need to create helpers for things like loops, and you may be hindered by Python's limits on recursion, but FWIW Scheme's or Haskell's functions have the exact same limitation, the primary difference being they're nowhere near as statement-heavy as Python).
setHeavyweightProperty = triggers('cache:dirty')(
lambda self, property, value: 'code')
@triggers('cache:dirty')
def setHeavyweightProperty(self, property, value):
# code
> First, the multi-line anonymous lambda being used as the target of the decorator.
Python has no issue with that, it's just hard to do it because Python's lambdas can only contain expressions which can be rather limited in a statements-heavy language.
> Second, a function being called with another function as its argument as an expression within an instance method definition.
That's because your "instance method definition" is not syntactically correct, the capability itself exists. A "method definition" is nothing more than a function defined within a class scope. In fact you can do things like that:
>>> def method_outside(self):
... return self.wedding
...
>>> class SomeType:
... whose = method_outside
...
>>> s = SomeType()
>>> s.wedding = "Amanda"
>>> s.whose()
'Amanda'
>>> method_outside(s)
'Amanda'
>>> from collections import namedtuple
>>> o = namedtuple('N', 'wedding')(wedding="Jim")
>>> method_outside(o)
'Jim'
>>>The only thing python does not like is multi-line lambdas. You can target a lambda with decorators, just like you can target any callable. I'm not sure if I correctly parsed what you mean by "a function being called with another function as its argument as an expression within an instance method definition", but I'm pretty sure python can do that. Here is some demonstration code (see RaganwaldWidgetViewThree):
https://gist.github.com/3495990
And finally here is the translation of the before/after/etc. method combinators:
https://gist.github.com/3495985
But I might have misunderstood waitLevel, can you explain what it is for?
Better, just use Function.prototype.bind, 0 bytes gzipped with Vanilla JS.
somethingElse =
render: => # do some renderingI just tested and it looks like you can hack it by doing
_this = somethingElse =
render: => @renderMe # @ is somethingElse