2012/9/25 Brandon Bloom snprbo...@gmail.com
clojurescript gives no access to javascript's delete operator.
There is a js-delete macro in core. It uses the same form as your proposed
adel form.
Oh, beg your pardon, I have overlooked that.
I have to admit, a del! form for deleting
2012/9/13 David Nolen dnolen.li...@gmail.com
If people are encountering reasons
to use it - something is missing from ClojureScript that needs to be
provided.
I think I found such a reason: clojurescript gives no access to
javascript's delete operator. Deleting is not the same as setting to
clojurescript gives no access to javascript's delete operator.
There is a js-delete macro in core. It uses the same form as your proposed
adel form.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to
On Wed, Sep 12, 2012 at 10:16 PM, Alexander Hudek alexan...@hudek.org wrote:
I've used it in conjunction with goog/base due to a problem with
simple/advanced compilation. I'm not sure if things have changed since I
encountered this problem, or if there is something else I'm doing wrong. See
I've used it in conjunction with goog/base due to a problem with
simple/advanced compilation. I'm not sure if things have changed since I
encountered this problem, or if there is something else I'm doing wrong.
See the code and comment below. The deactivated this-as code only worked
with
Would it be correct to interpret this as another vote for JVM Clojure's
proxy macro?
On Wednesday, September 12, 2012 7:16:37 PM UTC-7, Alexander Hudek wrote:
I've used it in conjunction with goog/base due to a problem with
simple/advanced compilation. I'm not sure if things have changed
From your description of how proxy would work, yes.
On Sunday, September 16, 2012 6:48:44 PM UTC-4, Brandon Bloom wrote:
Would it be correct to interpret this as another vote for JVM Clojure's
proxy macro?
On Wednesday, September 12, 2012 7:16:37 PM UTC-7, Alexander Hudek wrote:
I've used
On Wed, Sep 12, 2012 at 7:56 PM, Kevin Downey redc...@gmail.com wrote:
I've used it to make ClojureScript functions in to javascript object
constructors
(defn Foo [] (js* /*) (js* */))
results in the generated return being commented out, so (Foo.) works
I use this in a macro for creating
On Wed, Sep 12, 2012 at 7:12 PM, Brandon Bloom snprbo...@gmail.com wrote:
I'm exploring some changes to the ClojureScript compiler backend and am
curious if anyone is using one particular implementation detail: The js*
special form.
Note that I'm not asking about the js/ pseudo-namespace,
david, what's the recommended way to convert between cljs and native js
objects for interop with existing js code?
On Thursday, September 13, 2012 10:13:59 AM UTC-4, David Nolen wrote:
On Wed, Sep 12, 2012 at 7:12 PM, Brandon Bloom
snpr...@gmail.comjavascript:
wrote:
I'm exploring some
On Thu, Sep 13, 2012 at 11:03 AM, Dustin Getz dustin.g...@gmail.com wrote:
david, what's the recommended way to convert between cljs and native js
objects for interop with existing js code?
There is no good conversion from CLJS data structures to JS data
structures, at least not enough good
Just a reminder that people should not be using it at all. It may be
removed at anytime without warning.
I'm considering replacing it with a form which must return JS AST nodes,
instead of a JS source code string.
If people are encountering reasons
to use it - something is missing
On Thu, Sep 13, 2012 at 1:10 PM, Brandon Bloom snprbo...@gmail.com wrote:
Just a reminder that people should not be using it at all. It may be
removed at anytime without warning.
I'm considering replacing it with a form which must return JS AST nodes,
instead of a JS source code string.
Why
Why should the backend have to deal with JS AST nodes?
I'm considering changing the emit phase to produce a Google Closure
Compiler AST. This would have several benefits:
1. The emit phase would become functional (returning an AST) instead
of procedural (printing source).
2. Test
On Thu, Sep 13, 2012 at 1:31 PM, Brandon Bloom snprbo...@gmail.com wrote:
Why should the backend have to deal with JS AST nodes?
I'm considering changing the emit phase to produce a Google Closure Compiler
AST. This would have several benefits:
The emit phase would become functional
I use it for fast string concatenation
https://www.refheap.com/paste/5060
JW
On Thursday, September 13, 2012 1:12:21 AM UTC+2, Brandon Bloom wrote:
I'm exploring some changes to the ClojureScript compiler backend and am
curious if anyone is using one particular implementation detail: The
I'm exploring some changes to the ClojureScript compiler backend and am
curious if anyone is using one particular implementation detail: The js*
special form.
Note that I'm not asking about the js/ pseudo-namespace, only the js*
special form.
Are you using it in your ClojureScript projects?
I've used it to make ClojureScript functions in to javascript object
constructors
(defn Foo [] (js* /*) (js* */))
results in the generated return being commented out, so (Foo.) works
I use this in a macro for creating new types that are based on
existing Google Closure types
On Wed, Sep 12,
Interesting. Would that use case be covered by an implementation of the
proxy macro, et al? Said implementation could produce proper Google Closure
javadocs with @extends / @implements, as well as calls to goog.inherit
On Wednesday, September 12, 2012 4:56:24 PM UTC-7, red...@gmail.com wrote:
19 matches
Mail list logo
