Thus, a syntax can be chosen any (since @ is used in Ruby-style for
"instance variables"). Python uses such decorators not only to wrap some
functions (i.e. @foo def bar ... is just a sugar for bar = foo(bar)) but
also to change a semantics of some methods -- e.g. @classmethod decorator,
etc.
function handleRequest (...args) {
let data = [...]
return data
}
I.e. before entering the handleRequest first checkArguments and
validatePost methods should be called. Then the handleRequest itself and
after that formatResponse.
Thus, methods-annotations should accept/return a data of a special format.
If e.g. checkArguments isn't passed, it should either throw or return a
special error data (a signal that other annotation in chain shouldn't
continue). In the successful passing, it just returns handled data which are
passed next to the following annotation/decorator.
Dmitry.
Hello,
What about to have a bit sugar for AOP in Harmony in respect of
*decorators*or (pre/post)
*annotations*?
Python has a common strategy of decorating an annotating methods. E.g.:
def foo(original_fn):
def decorated_fn(x):
print("Log", x)
original_fn(x)
return decorated fn
@foo
def bar(x):
print("bar: ", x)
Thus, a syntax can be chosen any (since `@` is used in Ruby-style for
"instance variables"). Python uses such decorators not only to wrap some
functions (i.e. `@foo def bar ...` is just a sugar for `bar = foo(bar)`) but
also to change a semantics of some methods -- e.g. `@classmethod` decorator,
etc.
Additional info for Pythons decorators:
http://www.python.org/dev/peps/pep-0318/
Also, besides the Python's common decorators, `pre-` and `post-`
`annotations` can be considered.
E.g. (abstract syntax):
[pre checkArguments]
[pre validatePost]
[post formatResponse]
function handleRequest (...args) {
let data = [...]
return data
}
I.e. before entering the `handleRequest` first `checkArguments` and
`validatePost` methods should be called. Then the `handleRequest` itself and
after that `formatResponse`.
Thus, methods-annotations should accept/return a data of a special format.
If e.g. `checkArguments` isn't passed, it should either throw or return a
special `error` data (a signal that other annotation in chain shouldn't
continue). In the successful passing, it just returns handled data which are
passed next to the following annotation/decorator.
Dmitry.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20101230/3edf7ccd/attachment.html>
Hello,
What about to have a bit sugar for AOP in Harmony in respect of decoratorsor (pre/post) annotations?
Python has a common strategy of decorating an annotating methods. E.g.:
def foo(original_fn): def decorated_fn(x): print("Log", x) original_fn(x) return decorated fn
@foo def bar(x): print("bar: ", x)
Thus, a syntax can be chosen any (since
@
is used in Ruby-style for "instance variables"). Python uses such decorators not only to wrap some functions (i.e.@foo def bar ...
is just a sugar forbar = foo(bar)
) but also to change a semantics of some methods -- e.g.@classmethod
decorator, etc.Additional info for Pythons decorators: www.python.org/dev/peps/pep-0318
Also, besides the Python's common decorators,
pre-
andpost-
annotations
can be considered.E.g. (abstract syntax):
[pre checkArguments] [pre validatePost] [post formatResponse]
function handleRequest (...args) { let data = [...] return data }
I.e. before entering the
handleRequest
firstcheckArguments
andvalidatePost
methods should be called. Then thehandleRequest
itself and after thatformatResponse
.Thus, methods-annotations should accept/return a data of a special format. If e.g.
checkArguments
isn't passed, it should either throw or return a specialerror
data (a signal that other annotation in chain shouldn't continue). In the successful passing, it just returns handled data which are passed next to the following annotation/decorator.Dmitry.