Re: In your opinion, what's the best, and what's the worst aspects of using Clojure?
We added this as part of our standard logging, not only when exceptions are raised. It does help a lot in prod... Luc P. On Dec 27, 2013, at 11:33 PM, guns wrote: On Fri 27 Dec 2013 at 11:23:22PM -0500, Lee Spector wrote: On Dec 27, 2013, at 11:18 PM, guns wrote: (defmacro dump-locals [] ... ` When and where do you call this? I call this inside of the closest function that raised the exception. Ah, so you have to see an exception, edit your code to include a call to this, re-run, and get to the same exception. So it will only help for exception-raising situations that are easy to repeat, which mine often are not. Like you mentioned, I've heard nrepl-ritz does this in emacs, and David Greenberg has something like this set up for vim: https://github.com/dgrnbrg/vim-redl It would be really nice if this sort of thing -- dumping all locals when an exception is raised -- could be done in an IDE-independent way. FWIW my code is often running via lein run, and when one of those runs raises an exception I'd really like to get more information about what happened. -Lee -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
case/java interop weirdness
I'm sure I'm missing something very simple here, but I'm damned if I can see it. I'm trying to use the Java Rome RSS/Atom utility library from Clojure. The Rome Fetcher library defines a FeedEvent class, which among other things defines a number of static final string members: https://github.com/rometools/rome-fetcher/blob/master/src/main/java/org/rometools/fetcher/FetcherEvent.java#L17 Using the following simple project.clj: (defproject rsstest 1.0 :dependencies [[org.clojure/clojure 1.5.1] [org.rometools/rome-fetcher 1.2]]) I see the following: user= (import 'org.rometools.fetcher.FetcherEvent) org.rometools.fetcher.FetcherEvent user= FetcherEvent/EVENT_TYPE_FEED_POLLED FEED_POLLED user= (case FetcherEvent/EVENT_TYPE_FEED_POLLED #_= FetcherEvent/EVENT_TYPE_FEED_POLLED :ok) IllegalArgumentException No matching clause: FEED_POLLED user/eval1132 (NO_SOURCE_FILE:1) For some reason, case doesn't seem to be able to match on a static final String member of a Java class? Everything works fine if I use the literal string value though: user= (case FetcherEvent/EVENT_TYPE_FEED_POLLED #_= FEED_POLLED :ok) :ok I'd be very grateful for any guidance as to what's going on here? -- paul.butcher-msgCount++ Silverstone, Brands Hatch, Donington Park... Who says I have a one track mind? http://www.paulbutcher.com/ LinkedIn: http://www.linkedin.com/in/paulbutcher Skype: paulrabutcher -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: case/java interop weirdness
The test clauses of case expressions are not evaluated, so that case is trying to match the symbol 'FetcherEvent/EVENT_TYPE_FEED_POLLED, not the value of FetcherEvent/EVENT_TYPE_FEED_POLLED. Paul Butcher writes: I'm sure I'm missing something very simple here, but I'm damned if I can see it. I'm trying to use the Java Rome RSS/Atom utility library from Clojure. The Rome Fetcher library defines a FeedEvent class, which among other things defines a number of static final string members: https://github.com/rometools/rome-fetcher/blob/master/src/main/java/org/rometools/fetcher/FetcherEvent.java#L17 Using the following simple project.clj: (defproject rsstest 1.0 :dependencies [[org.clojure/clojure 1.5.1] [org.rometools/rome-fetcher 1.2]]) I see the following: user= (import 'org.rometools.fetcher.FetcherEvent) org.rometools.fetcher.FetcherEvent user= FetcherEvent/EVENT_TYPE_FEED_POLLED FEED_POLLED user= (case FetcherEvent/EVENT_TYPE_FEED_POLLED #_= FetcherEvent/EVENT_TYPE_FEED_POLLED :ok) IllegalArgumentException No matching clause: FEED_POLLED user/eval1132 (NO_SOURCE_FILE:1) For some reason, case doesn't seem to be able to match on a static final String member of a Java class? Everything works fine if I use the literal string value though: user= (case FetcherEvent/EVENT_TYPE_FEED_POLLED #_= FEED_POLLED :ok) :ok I'd be very grateful for any guidance as to what's going on here? -- paul.butcher-msgCount++ Silverstone, Brands Hatch, Donington Park... Who says I have a one track mind? http://www.paulbutcher.com/ LinkedIn: http://www.linkedin.com/in/paulbutcher Skype: paulrabutcher -- -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Looking to migrate thousands of Clojure applications from 1.2 to 1.5.
Will do. Once the migration is steady (that is, we have a 1.2 and 1.5 environment running concurrently), I'll write a post about the experience and how we will eventually decommission the 1.2 environment. On Tuesday, December 24, 2013 1:48:22 PM UTC-5, Sean Corfield wrote: On Tue, Dec 24, 2013 at 7:23 AM, solo...@gmail.com javascript: wrote: Yes, after looking into this, upgrading the libraries before upgrade the Clojure version is unfeasible in our case. I prefer not to keep a 1.2 environment around forever but take our time phasing it out to avoid service disruption. I think the dual environment consensus here is the way to go. Please keep us posted on how this goes - I think it's an interesting case study for what happens with a large legacy code base. Fortunately the 1.2 - 1.3 changes were the biggest we've had to deal with so far and all the signs indicate we won't have to deal with that again, so this is a pain that only early adopters will be feeling. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: In your opinion, what's the best, and what's the worst aspects of using Clojure?
:pre and :post http://blog.fogus.me/2009/12/21/clojures-pre-and-post/ are
great tools, but must be used at the very top of your function. You can
also use assert http://clojuredocs.org/clojure_core/clojure.core/assert,
at any location in your function. I've also had success with Prismatic's
Schema https://github.com/Prismatic/schema.
Hth
Tim Washington
Interruptsoftware.com http://interruptsoftware.com
On Sat, Dec 28, 2013 at 8:52 PM, larry google groups
lawrencecloj...@gmail.com wrote:
What still scars me in terms of incorporating Clojure as a language of
choice in more
complicated projects I work on in my other life, is the error reporting
facility. The
errors sometimes might as well just say 'I just cannot run!'. It would
be nice if
there was some facility to approximately point to some s-exp or line
numbers.
I agree that some of the stacktraces make it difficult to track down where
an error is. I've lately dealt with that by writing a lot of :pre and :post
assertions. That tends to narrow everything down very quickly. For
instance:
(defn get-count [request]
{:pre [
(= (type request) clojure.lang.PersistentHashMap)
(= (type (get-in request [:params :item-type])) java.lang.String)
]
:post [
(= (type %) java.lang.Long)
(or (pos? %) (zero? %))
]}
(monger/get-count (get-in request [:params :item-type])))
At the top level of my app, I wrap everything in a try/catch and print out
(clojure.stacktrace//print-stack-trace e). It's a bit of work, but once I
wrote enough :pre and :post conditions they became sufficient to give me
exact information about where any error occurred.
On Friday, December 27, 2013 8:48:55 PM UTC-5, Guru Devanla wrote:
Seconded on Error reporting.
I have been playing around with Clojure for sometime now and also
completed almost 150 of the 4clojure problems. What still scars me in terms
of incorporating Clojure as a language of choice in more complicated
projects I work on in my other life, is the error reporting facility. The
errors sometimes might as well just say 'I just cannot run!'. It would be
nice if there was some facility to approximately point to some s-exp or
line numbers.
May be I am missing some workflow used by other expert users. Can someone
throw more light on this.
Thanks
Guru
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: case/java interop weirdness
On 30 Dec 2013, at 13:57, Nicola Mometto brobro...@gmail.com wrote: The test clauses of case expressions are not evaluated, so that case is trying to match the symbol 'FetcherEvent/EVENT_TYPE_FEED_POLLED, not the value of FetcherEvent/EVENT_TYPE_FEED_POLLED. Ah - I was aware of the requirement for the constants to be compile-time literals, but assumed that give that they were final static Strings, that would work. Obviously not. Is there any way to achieve the effect I'm after with case? Or do I need to switch to condp? -- paul.butcher-msgCount++ Silverstone, Brands Hatch, Donington Park... Who says I have a one track mind? http://www.paulbutcher.com/ LinkedIn: http://www.linkedin.com/in/paulbutcher Skype: paulrabutcher -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Looking to migrate thousands of Clojure applications from 1.2 to 1.5.
Thanks, Alex. I agree that migrating these tiny 1.2 applications would be wasted effort as the majority won't change and will become obsolete soon anyway.The ones which will remain relevant will be easy to identify and may be worth migrating. Regarding testing, no, I have no confidence in these reports being well tested and I'm taking a very defensive stance against them. My view is they function adequately in their 1.2 bubble with all the copying and pasting with a slim chance of surviving outside of that. I've written a lengthy blog post on our internal forum on how to proceed. Basically, it's as follows: 1) Analysis: which contrib libraries we use, how we use them, and rank them accordingly. Find their 1.5 analogues or best alternative. 2) Get a 1.5 environment up and running for only our immediate team. The outside world will keep creating reports for the 1.2 environment. 3) Create a number of sample reports for the 1.5 environment and write a few educational docs. 4) Once the samples are done, update the report editor such that all new reports must conform to 1.5 standards. Old 1.2 reports will still be accessible. 5) 12 months after step 4, check which 1.2 reports are still being invoked. Migrate them, test them, and then shutdown the 1.2 environment. On Tuesday, December 24, 2013 2:46:08 PM UTC-5, Alex Baranosky wrote: Hi Solo, I did a big migration from 1.2 to 1.5 at work this past February. Here are a few of the things that I gleaned from that experience, i addition to the great advice mentioned already in this thread: * with 1000's of these applications, I'd take the approach of only migrating to 1.5 when there's a change needed, because there's a good chance a lot of them will never need to be modified. Any extra apps you need to migrate could be work down the drain. * on the other hand, you can get a nice groove going, and may want to do a bunch of reports in one go. The changes you may find can be repetitive. * to make sure you are only including namespaces that absolutely need to be used by your application, AND to convert the ns declarations into 1.5 format automatically I used https://github.com/technomancy/slamhound. Watch out for any macro-heavy code though, because Slamhound can miss dependencies used exclusively in macros. * are these reports tested? If not well tested be wary, because there were a lot of number-related changes from 1.2 to 1.3 * keep an eye out for duplicated patterns in the reports. If there are some common pieces you might be able to just migrate those to 1.5 and use them as a library for the other reports. YMMV. * Best, Alex On Tue, Dec 24, 2013 at 10:48 AM, Sean Corfield seanco...@gmail.comjavascript: wrote: On Tue, Dec 24, 2013 at 7:23 AM, solo...@gmail.com javascript: wrote: Yes, after looking into this, upgrading the libraries before upgrade the Clojure version is unfeasible in our case. I prefer not to keep a 1.2 environment around forever but take our time phasing it out to avoid service disruption. I think the dual environment consensus here is the way to go. Please keep us posted on how this goes - I think it's an interesting case study for what happens with a large legacy code base. Fortunately the 1.2 - 1.3 changes were the biggest we've had to deal with so far and all the signs indicate we won't have to deal with that again, so this is a pain that only early adopters will be feeling. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group
[ANN] Optimus asset loaders and transformations
Optimus https://github.com/magnars/optimus is a Ring middleware for
frontend performance optimization.
In order to do its optimization, it needs to rest on a first-class asset
concept in the Ring stack. So the most basic operation of Optimus is
serving assets from a list, with this minimal structure:
[{:path :contents}]
It serves the :contents if the request :uri matches :path.
Built on top of that is a bunch of operations that either help you:
- Load assets to put in the list
- Optimize the assets in the list somehow
- Decide how you want to serve the assets
- Link to the assets
For instance, transformations that change :path also set :original-path so
that the linking functions can refer to a known name.
So, Optimus is a replacement for compojure.route/resources, that includes a
separate middleware stack for asset transformations.
I'm announcing optimus-less https://github.com/magnars/optimus-less and
optimus-angular https://github.com/magnars/optimus-angular which both
show some interesting ways to extend Optimus.
https://gist.github.com/magnars/4b1f32a76523a4b39ef8#optimus-lessOptimus
LESS
Even tho Optimus itself doesn't do transpiling, building a transpiler to
use with Optimus is pretty nice. I created
optimus-lesshttps://github.com/magnars/optimus-less as
an example implementation.
Optimus LESS declares load-less-asset as a custom loader for .less files
with Optimus' load-assetmultimethod. This is in turn used by load-assets,
load-bundle and load-bundles - so everything works like before, but now it
also supports LESS files. Score!
It's about 20 lines of
codehttps://github.com/magnars/optimus-less/blob/master/src/optimus_less/core.clj,
including requires. And adding support for more transpilers require no
changes to Optimus itself.
https://gist.github.com/magnars/4b1f32a76523a4b39ef8#optimus-angularOptimus
Angular
This project offers two distinct features. It helps you:
- Prepopulate the Angular.JS template cache.
- Prepare JavaScript for minification with
ngminhttps://github.com/btford/ngmin
.
https://gist.github.com/magnars/4b1f32a76523a4b39ef8#prepopulating-the-angularjs-template-cachePrepopulating
the Angular.JS template cache
optimus-angular/create-template-cache is a custom Optimus asset loader. It
creates a virtual JavaScript asset that populates the Angular.JS template
cache with your given templates.
https://gist.github.com/magnars/4b1f32a76523a4b39ef8#preparing-javascript-for-minificationPreparing
JavaScript for minification
When minifying JavaScript, local variable names are changed to be just one
letter. This reduces file size, but disrupts some libraries that use clever
reflection tricks - like Angular.JS.
By transforming your assets with optimus-angular/prepare-for-minification,
these reflection tricks are replaced by an alternate syntax that still
functions after mangling of local names.
https://gist.github.com/magnars/4b1f32a76523a4b39ef8#in-summaryIn summary
Hopefully these examples show how Optimus is open for extension. So while
the core of Optimus is frontend optimization, the introduction of first
class assets open up new possibilities.
If you use Optimus or want to get started, please do let me know. I'm happy
to address any relevant issues. My goal is for Optimus to be a really solid
piece of software.
Thanks,
- Magnar
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Optimus asset loaders and transformations
Oh, if you checked out Optimus when I first announced it, here are some improvements since then: - Split strategies and optimizations so they can vary independently. - Add support for :base-path on assets for CDNs. - Add exporting of assets to disk. Also for CDNs. - Move Angular.JS features into its own projecthttp://github.com/magnars/optimus-angular . - Create extension point for asset loading. - Add Last-Modified headers. I remember someone asking about how Optimus interacts with other Ring middleware, in particular the wrap-not-modified middleware. Now that Optimus servers Last-Modified headers, that works very well. Just add ( ring.middleware.not-modified/wrap-not-modified) after (optimus/wrap) and you're serving 304 responses like a pro. :-) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[ANN] clj-refactor.el - A few Clojure refactorings for Emacs.
clj-refactor.el https://github.com/magnars/clj-refactor.el provides a set
of simple refactorings for Clojure in Emacs. It doesn't tackle the hard
problems, like cross-namespace renaming. Instead it gives you a little
quality of life while we're waiting.
https://gist.github.com/magnars/51ccab2b478d97b9aa17#thread--unwindThread
/ unwind
Given this:
(map square (filter even? [1 2 3 4 5]))
Start by wrapping it in a threading macro:
(- (map square (filter even? [1 2 3 4 5])))
And start threading away, using cljr-thread:
(- (filter even? [1 2 3 4 5])
(map square))
And again:
(- [1 2 3 4 5]
(filter even?)
(map square))
To revert this, there's cljr-unwind. Just read the examples in the other
direction.
https://gist.github.com/magnars/51ccab2b478d97b9aa17#introduce--expand-letIntroduce
/ expand let
Given this:
(defn handle-request
{:status 200
:body (find-body abc)})
With the cursor in front of (find-body abc), I do cljr-introduce-let:
(defn handle-request
{:status 200
:body (let [X (find-body abc)]
X)})
Now I have two cursors where the Xes are. Just type out the name, and press
enter. Of course, that's not where I wanted the let statement. So I do
cljr-expand-let:
(defn handle-request
(let [body (find-body abc)]
{:status 200
:body body}))
Yay.
https://gist.github.com/magnars/51ccab2b478d97b9aa17#automatic-insertion-of-namespace-declarationAutomatic
insertion of namespace declaration
When you open a blank .clj-file, clj-refactor inserts the namespace
declaration for you.
It will also add the relevant :use clauses in test files, normally using
clojure.test, but if you're depending on midje in your project.clj it uses
that instead.
https://gist.github.com/magnars/51ccab2b478d97b9aa17#more-stuffMore stuff
- When you rename a file, it will update the ns-declaration and then
query-replace new ns in project.
- You can add :require and :import to the ns, and when you're done it
jumps back to where you were.
https://gist.github.com/magnars/51ccab2b478d97b9aa17#in-summaryIn summary
This isn't the big refactoring lib that we're all waiting for. That would
require connecting to nREPL, analyzing ASTs, expanding macros, and a whole
lot of other problems.
Instead it adds a few helpful functions that are available right now.
And if you want to contribute, and maybe grow this into the refactorer's
dream - do let me know. I'm all for that. :-)
- Magnar
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: is there a tutorial about working at the REPL?
On Sun, Dec 29, 2013 at 1:30 PM, larry google groups lawrencecloj...@gmail.com wrote: Thanks for that. But the app has no problem reading the schema.edn file when I start the app with: java -jar admin-1-standalone.jar So why would it have trouble reading the file when I'm in the repl? Can you post the project (or just the EDN file)? It's hard to get specific without seeing more. My general REPL-driven debugging strategy is to run the code in question in smaller and smaller increments until I find the minimum piece of code that fails. That will help you pinpoint where the issue is. So, for instance, you know that (initiate-forms) fails, and you noted that it contains (read-string (slurp (clojure.java.io/resource config/schema.edn))). Given that, I would try each of the following in sequence: 1. (clojure.java.io/resource config/schema.edn) 2. (slurp (clojure.java.io/resource config/schema.edn)) 3. (read-string (slurp (clojure.java.io/resource config/schema.edn))) Of course, also include anything else in `initiate-forms`. Going through that may lead you to the problem, but if not please reply with the result of each of those expressions, including the details of any exception(s) thrown. Based on the error in your REPL session - John -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: case/java interop weirdness
To do it with case, you'd need to wrap case in a macro that expanded to `(case ~thingy ~(eval case1) ...) or something along those lines, with the evals snapping lookups like FetcherEvent/EVENT_TYPE_FEED_POLLED to the associated constants. This will have the effect of classloading the class with the constants at macroexpansion time, but that's likely happening anyway if you're importing that class. On Mon, Dec 30, 2013 at 9:07 AM, Paul Butcher p...@paulbutcher.com wrote: On 30 Dec 2013, at 13:57, Nicola Mometto brobro...@gmail.com wrote: The test clauses of case expressions are not evaluated, so that case is trying to match the symbol 'FetcherEvent/EVENT_TYPE_FEED_POLLED, not the value of FetcherEvent/EVENT_TYPE_FEED_POLLED. Ah - I was aware of the requirement for the constants to be compile-time literals, but assumed that give that they were final static Strings, that would work. Obviously not. Is there any way to achieve the effect I'm after with case? Or do I need to switch to condp? -- paul.butcher-msgCount++ Silverstone, Brands Hatch, Donington Park... Who says I have a one track mind? http://www.paulbutcher.com/ LinkedIn: http://www.linkedin.com/in/paulbutcher Skype: paulrabutcher -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[ANN] clojure.java.jdbc 0.3.1 released
Clojure contrib wrapper for JDBC. This release contains minor bug fixes compared to 0.3.0, with the main focus being an overhaul of docstrings etc to improve the auto-gen'd documentation: http://clojure.github.io/java.jdbc/ The community documentation on clojure-doc has also had a major overhaul: http://clojure-doc.org/articles/ecosystem/java_jdbc/home.html Details of this release: * Improve docstrings and add :arglists for better auto-generated documentation. * Make insert-sql private - technically a breaking change but it should never have been public: sorry folks! * Provide better protocol for setting parameters in prepared statements JDBC-86. * Fix parens in two deprecated tests JDBC-85. * Made create-table-ddl less aggressive about applying as-sql-name so only first name in a column spec is affected. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] clojure.java.jdbc 0.3.1 released
Just found a showstopping bug in 0.3.1 - 0.3.2 will be along shortly. TIL: protocols need implementations for both Object _and_ nil to work properly in the real world... :( Sean On Mon, Dec 30, 2013 at 8:46 AM, Sean Corfield seancorfi...@gmail.com wrote: Clojure contrib wrapper for JDBC. This release contains minor bug fixes compared to 0.3.0, with the main focus being an overhaul of docstrings etc to improve the auto-gen'd documentation: http://clojure.github.io/java.jdbc/ The community documentation on clojure-doc has also had a major overhaul: http://clojure-doc.org/articles/ecosystem/java_jdbc/home.html Details of this release: * Improve docstrings and add :arglists for better auto-generated documentation. * Make insert-sql private - technically a breaking change but it should never have been public: sorry folks! * Provide better protocol for setting parameters in prepared statements JDBC-86. * Fix parens in two deprecated tests JDBC-85. * Made create-table-ddl less aggressive about applying as-sql-name so only first name in a column spec is affected. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: protocols and overloading
On Sunday, December 29, 2013 10:11:47 PM UTC+1, tbc++ wrote: Not mentioned in Cedric's post are two other important things: Protocols can be extended to existing types. For example: (defprotocol IType (type-as-string [x])) (extend-protocol IType String (type-as-string [x] string) Integer (type-as-string [x] integer)) = (type-as-string 42) integer Here we are adding new methods to sealed closed classes that already exist in the JVM. We never modify these classes, we simply extend our protocol to them. Secondly, all protocol functions are namespaced. This allows us to extend classes without fear of overwriting existing methods. This then is more powerful than monkey patching in Ruby or Python as the resulting method is more like 42.user_type-as-string(). Clojure's namespace system then allows you to refer to one method or the other just as you would any normal functions. You're not really adding methods to classes in Clojure. You're just defining external functions. Can you make them private or protected? In my opinion, the Expression Problem in FP and OOP are two different problems. In FP you can solve it more easily because you use pseudo-classes which don't behave like real classes at all. The proof of this is that any sufficiently dynamic OO language can solve the problem the same way Clojure does just by using classes with no methods and by using overloading resolved at runtime. Of course, you don't do that in OOP because you want to work with real classes. For instance, C# has extension methods which let you add methods to existing classes without any recompilation. Problem solved? I don't think so. Extension methods are just static functions that emulate the behavior of instance methods, but without any kind of encapsulation and possibility of inheritance. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] clojure.java.jdbc 0.3.1 released
The tests have been updated to included nil cases now so I shouldn't make the same mistake again. On Mon, Dec 30, 2013 at 8:57 AM, Sean Corfield seancorfi...@gmail.com wrote: Just found a showstopping bug in 0.3.1 - 0.3.2 will be along shortly. TIL: protocols need implementations for both Object _and_ nil to work properly in the real world... :( Sean On Mon, Dec 30, 2013 at 8:46 AM, Sean Corfield seancorfi...@gmail.com wrote: Clojure contrib wrapper for JDBC. This release contains minor bug fixes compared to 0.3.0, with the main focus being an overhaul of docstrings etc to improve the auto-gen'd documentation: http://clojure.github.io/java.jdbc/ The community documentation on clojure-doc has also had a major overhaul: http://clojure-doc.org/articles/ecosystem/java_jdbc/home.html Details of this release: * Improve docstrings and add :arglists for better auto-generated documentation. * Make insert-sql private - technically a breaking change but it should never have been public: sorry folks! * Provide better protocol for setting parameters in prepared statements JDBC-86. * Fix parens in two deprecated tests JDBC-85. * Made create-table-ddl less aggressive about applying as-sql-name so only first name in a column spec is affected. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: protocols and overloading
On Mon, Dec 30, 2013 at 12:13 PM, Massimiliano Tomassoli kiuhn...@gmail.com wrote: On Sunday, December 29, 2013 10:11:47 PM UTC+1, tbc++ wrote: Not mentioned in Cedric's post are two other important things: Protocols can be extended to existing types. For example: (defprotocol IType (type-as-string [x])) (extend-protocol IType String (type-as-string [x] string) Integer (type-as-string [x] integer)) = (type-as-string 42) integer Here we are adding new methods to sealed closed classes that already exist in the JVM. We never modify these classes, we simply extend our protocol to them. Secondly, all protocol functions are namespaced. This allows us to extend classes without fear of overwriting existing methods. This then is more powerful than monkey patching in Ruby or Python as the resulting method is more like 42.user_type-as-string(). Clojure's namespace system then allows you to refer to one method or the other just as you would any normal functions. You're not really adding methods to classes in Clojure. You're just defining external functions. Can you make them private or protected? In my opinion, the Expression Problem in FP and OOP are two different problems. In FP you can solve it more easily because you use pseudo-classes which don't behave like real classes at all. The proof of this is that any sufficiently dynamic OO language can solve the problem the same way Clojure does just by using classes with no methods and by using overloading resolved at runtime. Of course, you don't do that in OOP because you want to work with real classes. For instance, C# has extension methods which let you add methods to existing classes without any recompilation. Problem solved? I don't think so. Extension methods are just static functions that emulate the behavior of instance methods, but without any kind of encapsulation and possibility of inheritance. Encapsulation is less important without a lot of mutable state lying around, and remains important mainly at module boundaries, not class-like boundaries, where code belonging to different programmers comes into contact. If I change the internals of doohickey A and that breaks doohickey B inside the same module, I can fix B, and I know how to, and I know to do so as soon as I change A. It's when someone else changes doohickey C in a different module that I'm in trouble if I'm depending on the internals, but then hopefully there's an encapsulation boundary at the module boundary between my stuff and doohickey C. As for inheritance, it's *highly* overrated, complecting as it does composition and polymorphism. We Clojurians tend to keep those separated, and as a result protocols are purely about polymorphism while composition is dealt with in some orthogonal way. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] clj-refactor.el - A few Clojure refactorings for Emacs.
Hi Magnar,
I've been using this library for maybe a month. The refactorings I use by
far the most are renaming files, and threading/unthreading. Thanks for your
work on this.
On Mon, Dec 30, 2013 at 7:52 AM, Magnar Sveen magn...@gmail.com wrote:
clj-refactor.el https://github.com/magnars/clj-refactor.el provides a
set of simple refactorings for Clojure in Emacs. It doesn't tackle the hard
problems, like cross-namespace renaming. Instead it gives you a little
quality of life while we're waiting.
https://gist.github.com/magnars/51ccab2b478d97b9aa17#thread--unwindThread
/ unwind
Given this:
(map square (filter even? [1 2 3 4 5]))
Start by wrapping it in a threading macro:
(- (map square (filter even? [1 2 3 4 5])))
And start threading away, using cljr-thread:
(- (filter even? [1 2 3 4 5])
(map square))
And again:
(- [1 2 3 4 5]
(filter even?)
(map square))
To revert this, there's cljr-unwind. Just read the examples in the other
direction.
https://gist.github.com/magnars/51ccab2b478d97b9aa17#introduce--expand-letIntroduce
/ expand let
Given this:
(defn handle-request
{:status 200
:body (find-body abc)})
With the cursor in front of (find-body abc), I do cljr-introduce-let:
(defn handle-request
{:status 200
:body (let [X (find-body abc)]
X)})
Now I have two cursors where the Xes are. Just type out the name, and
press enter. Of course, that's not where I wanted the let statement. So I
do cljr-expand-let:
(defn handle-request
(let [body (find-body abc)]
{:status 200
:body body}))
Yay.
https://gist.github.com/magnars/51ccab2b478d97b9aa17#automatic-insertion-of-namespace-declarationAutomatic
insertion of namespace declaration
When you open a blank .clj-file, clj-refactor inserts the namespace
declaration for you.
It will also add the relevant :use clauses in test files, normally using
clojure.test, but if you're depending on midje in your project.clj it
uses that instead.
https://gist.github.com/magnars/51ccab2b478d97b9aa17#more-stuffMore
stuff
- When you rename a file, it will update the ns-declaration and then
query-replace new ns in project.
- You can add :require and :import to the ns, and when you're done it
jumps back to where you were.
https://gist.github.com/magnars/51ccab2b478d97b9aa17#in-summaryIn
summary
This isn't the big refactoring lib that we're all waiting for. That would
require connecting to nREPL, analyzing ASTs, expanding macros, and a whole
lot of other problems.
Instead it adds a few helpful functions that are available right now.
And if you want to contribute, and maybe grow this into the refactorer's
dream - do let me know. I'm all for that. :-)
- Magnar
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: protocols and overloading
On Sunday, December 29, 2013 11:30:16 PM UTC+1, Cedric Greevey wrote: On Sun, Dec 29, 2013 at 4:11 PM, Timothy Baldridge tbald...@gmail.comjavascript: wrote: Not mentioned in Cedric's post are two other important things: Protocols can be extended to existing types. These are important for the Expression Problem, but not for the OP's query as originally stated, which simply asked for the contrast with overloading. That contrast is dynamic vs. static dispatch. As for C++ being able to solve the Expression Problem and thus being equally powerful, well, both languages are also Turing complete. But which will generally let you be more expressive, with less ceremony and verbosity? Which has templates and macros that are unhygienic and a bugbear to work with, and which has macros that are very safe and clean? What I was saying was more subtle. If C++ can solve the Expression Problem the same way Clojure does, why do you say that Clojure's solution is acceptable whereas C++ programmers don't accept the same solution for C++? That's simple: external functions are not real methods. So we're accepting Clojure's solution because Clojure doesn't support real methods and objects, but we're rejecting the same solution in C++ because C++ *does* have real methods and objects. Isn't that absurd? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: protocols and overloading
On Mon, Dec 30, 2013 at 12:30 PM, Massimiliano Tomassoli kiuhn...@gmail.com wrote: On Sunday, December 29, 2013 11:30:16 PM UTC+1, Cedric Greevey wrote: On Sun, Dec 29, 2013 at 4:11 PM, Timothy Baldridge tbald...@gmail.comwrote: Not mentioned in Cedric's post are two other important things: Protocols can be extended to existing types. These are important for the Expression Problem, but not for the OP's query as originally stated, which simply asked for the contrast with overloading. That contrast is dynamic vs. static dispatch. As for C++ being able to solve the Expression Problem and thus being equally powerful, well, both languages are also Turing complete. But which will generally let you be more expressive, with less ceremony and verbosity? Which has templates and macros that are unhygienic and a bugbear to work with, and which has macros that are very safe and clean? What I was saying was more subtle. If C++ can solve the Expression Problem the same way Clojure does, why do you say that Clojure's solution is acceptable whereas C++ programmers don't accept the same solution for C++? That's simple: external functions are not real methods. So we're accepting Clojure's solution because Clojure doesn't support real methods and objects, but we're rejecting the same solution in C++ because C++ *does* have real methods and objects. Isn't that absurd? I think you'll need to define what you mean by real methods and objects, and in what way the word real is supposed to be establishing a contrast. A contrast with what, exactly? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: protocols and overloading
On Monday, December 30, 2013 6:27:05 PM UTC+1, Cedric Greevey wrote: On Mon, Dec 30, 2013 at 12:13 PM, Massimiliano Tomassoli kiuh...@gmail.com javascript: wrote: On Sunday, December 29, 2013 10:11:47 PM UTC+1, tbc++ wrote: Not mentioned in Cedric's post are two other important things: Protocols can be extended to existing types. For example: (defprotocol IType (type-as-string [x])) (extend-protocol IType String (type-as-string [x] string) Integer (type-as-string [x] integer)) = (type-as-string 42) integer Here we are adding new methods to sealed closed classes that already exist in the JVM. We never modify these classes, we simply extend our protocol to them. Secondly, all protocol functions are namespaced. This allows us to extend classes without fear of overwriting existing methods. This then is more powerful than monkey patching in Ruby or Python as the resulting method is more like 42.user_type-as-string(). Clojure's namespace system then allows you to refer to one method or the other just as you would any normal functions. You're not really adding methods to classes in Clojure. You're just defining external functions. Can you make them private or protected? In my opinion, the Expression Problem in FP and OOP are two different problems. In FP you can solve it more easily because you use pseudo-classes which don't behave like real classes at all. The proof of this is that any sufficiently dynamic OO language can solve the problem the same way Clojure does just by using classes with no methods and by using overloading resolved at runtime. Of course, you don't do that in OOP because you want to work with real classes. For instance, C# has extension methods which let you add methods to existing classes without any recompilation. Problem solved? I don't think so. Extension methods are just static functions that emulate the behavior of instance methods, but without any kind of encapsulation and possibility of inheritance. Encapsulation is less important without a lot of mutable state lying around, and remains important mainly at module boundaries, not class-like boundaries, where code belonging to different programmers comes into contact. If I change the internals of doohickey A and that breaks doohickey B inside the same module, I can fix B, and I know how to, and I know to do so as soon as I change A. It's when someone else changes doohickey C in a different module that I'm in trouble if I'm depending on the internals, but then hopefully there's an encapsulation boundary at the module boundary between my stuff and doohickey C. As for inheritance, it's *highly* overrated, complecting as it does composition and polymorphism. We Clojurians tend to keep those separated, and as a result protocols are purely about polymorphism while composition is dealt with in some orthogonal way. That's your opinion and I respect that. Maybe someday I'll come around to seeing things your way as I delve into Clojure, but I doubt it :) But I still think that we can't compare OOP and non-OOP languages w.r.t. the Expression Problem. If the Expression Problem consists in extending classes then non-OOP languages must be excluded because they don't have classes. We can't put datatypes and classes on the same level. They're just different things. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: protocols and overloading
C# extension methods are not polymorphic either. For example, casting a object to a parent type will cause a different extension method to be run. This is not the case in normal polymorphism, or for protocols (Clojure is a dynamic language, so casting doesn't exist anyways). You're right, you can (and I have) implement protocols in almost any language, even C++. It's just much more ugly and unidiomatic in c++. And what Cedric says is correct, encapsulation is rarely a good thing, and inheritance is overrated. Since Clojure's extend function accepts a hashmap of method names and functions, you can easily build stock implementations by putting standard implementation functions into a hashmap and then assoc'ing in new functions to override behavior. On Mon, Dec 30, 2013 at 10:31 AM, Cedric Greevey cgree...@gmail.com wrote: On Mon, Dec 30, 2013 at 12:30 PM, Massimiliano Tomassoli kiuhn...@gmail.com wrote: On Sunday, December 29, 2013 11:30:16 PM UTC+1, Cedric Greevey wrote: On Sun, Dec 29, 2013 at 4:11 PM, Timothy Baldridge tbald...@gmail.comwrote: Not mentioned in Cedric's post are two other important things: Protocols can be extended to existing types. These are important for the Expression Problem, but not for the OP's query as originally stated, which simply asked for the contrast with overloading. That contrast is dynamic vs. static dispatch. As for C++ being able to solve the Expression Problem and thus being equally powerful, well, both languages are also Turing complete. But which will generally let you be more expressive, with less ceremony and verbosity? Which has templates and macros that are unhygienic and a bugbear to work with, and which has macros that are very safe and clean? What I was saying was more subtle. If C++ can solve the Expression Problem the same way Clojure does, why do you say that Clojure's solution is acceptable whereas C++ programmers don't accept the same solution for C++? That's simple: external functions are not real methods. So we're accepting Clojure's solution because Clojure doesn't support real methods and objects, but we're rejecting the same solution in C++ because C++ *does* have real methods and objects. Isn't that absurd? I think you'll need to define what you mean by real methods and objects, and in what way the word real is supposed to be establishing a contrast. A contrast with what, exactly? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: protocols and overloading
On Monday, December 30, 2013 6:31:52 PM UTC+1, Cedric Greevey wrote: On Mon, Dec 30, 2013 at 12:30 PM, Massimiliano Tomassoli kiuh...@gmail.com javascript: wrote: On Sunday, December 29, 2013 11:30:16 PM UTC+1, Cedric Greevey wrote: On Sun, Dec 29, 2013 at 4:11 PM, Timothy Baldridge tbald...@gmail.comwrote: Not mentioned in Cedric's post are two other important things: Protocols can be extended to existing types. These are important for the Expression Problem, but not for the OP's query as originally stated, which simply asked for the contrast with overloading. That contrast is dynamic vs. static dispatch. As for C++ being able to solve the Expression Problem and thus being equally powerful, well, both languages are also Turing complete. But which will generally let you be more expressive, with less ceremony and verbosity? Which has templates and macros that are unhygienic and a bugbear to work with, and which has macros that are very safe and clean? What I was saying was more subtle. If C++ can solve the Expression Problem the same way Clojure does, why do you say that Clojure's solution is acceptable whereas C++ programmers don't accept the same solution for C++? That's simple: external functions are not real methods. So we're accepting Clojure's solution because Clojure doesn't support real methods and objects, but we're rejecting the same solution in C++ because C++ *does* have real methods and objects. Isn't that absurd? I think you'll need to define what you mean by real methods and objects, and in what way the word real is supposed to be establishing a contrast. A contrast with what, exactly? A class must support encapsulation, inheritance and polymorphism. If it doesn't, then it isn't a class. The same way, a method is a function that belongs to a class and can be public, private or protected. If a function is external to an object (i.e. it can't be made private or protected) than it isn't a method. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: protocols and overloading
If the Expression Problem consists in extending classes then non-OOP languages must be excluded because they don't have classes. No offense intended, but that is an incredibly wrong statement. Let's look up the official definition of the expression problem (via wikipedia): The goal is to define a datatype by cases, where one can add new cases to the datatype and new functions over the datatype, without recompiling existing code, and while retaining static type safety (e.g., no casts). The easiest way to solve this is via something like clojure's multimethods. However this is probably not the fastest way as it involves a lot of runtime computation. However, multiple dispatch has long been the defacto standard in solving the expression problem. Everything else pales in comparison to the raw flexibility of multimethods. Another way is via something like monkey-patching, but that has drawbacks of name collision. Or someone can go with the janky brute force visitor patter, and that involves a ton of boilerplate. What clojure's protocols allow is the addition of namespaced polymorphic functions that can be extended to any type. Here's an excellent article that goes over the flaws in OOP that make this problem much harder than it need be ( http://www.ibm.com/developerworks/library/j-clojure-protocols/ ) Timothy Timothy On Mon, Dec 30, 2013 at 10:45 AM, Massimiliano Tomassoli kiuhn...@gmail.com wrote: On Monday, December 30, 2013 6:27:05 PM UTC+1, Cedric Greevey wrote: On Mon, Dec 30, 2013 at 12:13 PM, Massimiliano Tomassoli kiuh...@gmail.com wrote: On Sunday, December 29, 2013 10:11:47 PM UTC+1, tbc++ wrote: Not mentioned in Cedric's post are two other important things: Protocols can be extended to existing types. For example: (defprotocol IType (type-as-string [x])) (extend-protocol IType String (type-as-string [x] string) Integer (type-as-string [x] integer)) = (type-as-string 42) integer Here we are adding new methods to sealed closed classes that already exist in the JVM. We never modify these classes, we simply extend our protocol to them. Secondly, all protocol functions are namespaced. This allows us to extend classes without fear of overwriting existing methods. This then is more powerful than monkey patching in Ruby or Python as the resulting method is more like 42.user_type-as-string(). Clojure's namespace system then allows you to refer to one method or the other just as you would any normal functions. You're not really adding methods to classes in Clojure. You're just defining external functions. Can you make them private or protected? In my opinion, the Expression Problem in FP and OOP are two different problems. In FP you can solve it more easily because you use pseudo-classes which don't behave like real classes at all. The proof of this is that any sufficiently dynamic OO language can solve the problem the same way Clojure does just by using classes with no methods and by using overloading resolved at runtime. Of course, you don't do that in OOP because you want to work with real classes. For instance, C# has extension methods which let you add methods to existing classes without any recompilation. Problem solved? I don't think so. Extension methods are just static functions that emulate the behavior of instance methods, but without any kind of encapsulation and possibility of inheritance. Encapsulation is less important without a lot of mutable state lying around, and remains important mainly at module boundaries, not class-like boundaries, where code belonging to different programmers comes into contact. If I change the internals of doohickey A and that breaks doohickey B inside the same module, I can fix B, and I know how to, and I know to do so as soon as I change A. It's when someone else changes doohickey C in a different module that I'm in trouble if I'm depending on the internals, but then hopefully there's an encapsulation boundary at the module boundary between my stuff and doohickey C. As for inheritance, it's *highly* overrated, complecting as it does composition and polymorphism. We Clojurians tend to keep those separated, and as a result protocols are purely about polymorphism while composition is dealt with in some orthogonal way. That's your opinion and I respect that. Maybe someday I'll come around to seeing things your way as I delve into Clojure, but I doubt it :) But I still think that we can't compare OOP and non-OOP languages w.r.t. the Expression Problem. If the Expression Problem consists in extending classes then non-OOP languages must be excluded because they don't have classes. We can't put datatypes and classes on the same level. They're just different things. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated -
Re: protocols and overloading
Ok, so if we take that definition of classes and methods, then what I'm saying is that the expression problem can be solved much easier via single dispatch polymorphic functions, and datatypes. At that point it's just a question of where the vtable is stored. In C++ it's in the object, in Clojure, it's in the function. Timothy On Mon, Dec 30, 2013 at 10:59 AM, Massimiliano Tomassoli kiuhn...@gmail.com wrote: On Monday, December 30, 2013 6:31:52 PM UTC+1, Cedric Greevey wrote: On Mon, Dec 30, 2013 at 12:30 PM, Massimiliano Tomassoli kiuh...@gmail.com wrote: On Sunday, December 29, 2013 11:30:16 PM UTC+1, Cedric Greevey wrote: On Sun, Dec 29, 2013 at 4:11 PM, Timothy Baldridge tbald...@gmail.comwrote: Not mentioned in Cedric's post are two other important things: Protocols can be extended to existing types. These are important for the Expression Problem, but not for the OP's query as originally stated, which simply asked for the contrast with overloading. That contrast is dynamic vs. static dispatch. As for C++ being able to solve the Expression Problem and thus being equally powerful, well, both languages are also Turing complete. But which will generally let you be more expressive, with less ceremony and verbosity? Which has templates and macros that are unhygienic and a bugbear to work with, and which has macros that are very safe and clean? What I was saying was more subtle. If C++ can solve the Expression Problem the same way Clojure does, why do you say that Clojure's solution is acceptable whereas C++ programmers don't accept the same solution for C++? That's simple: external functions are not real methods. So we're accepting Clojure's solution because Clojure doesn't support real methods and objects, but we're rejecting the same solution in C++ because C++ *does* have real methods and objects. Isn't that absurd? I think you'll need to define what you mean by real methods and objects, and in what way the word real is supposed to be establishing a contrast. A contrast with what, exactly? A class must support encapsulation, inheritance and polymorphism. If it doesn't, then it isn't a class. The same way, a method is a function that belongs to a class and can be public, private or protected. If a function is external to an object (i.e. it can't be made private or protected) than it isn't a method. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: protocols and overloading
On Monday, December 30, 2013 6:46:13 PM UTC+1, tbc++ wrote: And what Cedric says is correct, encapsulation is rarely a good thing, and inheritance is overrated. That's your opinion, not a fact. By saying that something is overrated you're just admitting that many people don't agree with you. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: protocols and overloading
There's been a trend against overuse of inheritance, first with java removing multiple-inheritance and the various private/protected nuanced inheritances, then generally accepted advice like 'prefer composition over inheritance'. Some people were still feeling the pain, and some of those are now using clojure partly because of it. With the whole 'decomplecting' philosophy, we have a way to talk about why it's so. I can just speak for myself, but finding someone defending it here is surprising. Also, clojure does have at least as many OOP trimmings as java, it's just made it easier to avoid them. When you say 'non-OOP languages that don't have classes', I don't think that includes clojure. It is a java underbelly by design, and java doesn't have open classes. Clojurescript gains some freedom via javascript's dynamic behavior, but the same abstractions (protocols) are applicable and useful there. On Mon, Dec 30, 2013 at 1:06 PM, Massimiliano Tomassoli kiuhn...@gmail.comwrote: On Monday, December 30, 2013 6:46:13 PM UTC+1, tbc++ wrote: And what Cedric says is correct, encapsulation is rarely a good thing, and inheritance is overrated. That's your opinion, not a fact. By saying that something is overrated you're just admitting that many people don't agree with you. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[ANN] clojure.java.jdbc 0.3.2 released
Clojure contrib wrapper for JDBC. This release contains minor bug fixes compared to 0.3.0, with the main focus being an overhaul of docstrings etc to improve the auto-gen'd documentation: http://clojure.github.io/java.jdbc/ The community documentation on clojure-doc has also had a major overhaul: http://clojure-doc.org/articles/ecosystem/java_jdbc/home.html Details of this release: * Add nil protocol implementation to ISQLParameter * Improve docstrings and add :arglists for better auto-generated documentation. * Make insert-sql private - technically a breaking change but it should never have been public: sorry folks! * Provide better protocol for setting parameters in prepared statements JDBC-86. * Fix parens in two deprecated tests JDBC-85. * Made create-table-ddl less aggressive about applying as-sql-name so only first name in a column spec is affected. (0.3.1 is broken and should not be used) -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
ANN: ClojureScript 0.0-2134
ClojureScript, the Clojure compiler that emits JavaScript source code. README and source code: https://github.com/clojure/clojurescript New release version: 0.0-2134 Leiningen dependency information: [org.clojure/clojurescript 0.0-2134] Enhancements: * Add ICloneable protocol, persistent collections now implement it. Add clone fn. * Fewer analysis passes Bug fixes: * PersistentHashSet.fromArray broken * CLJS-370: object? incorrectly handled nil -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: protocols and overloading
On Mon, Dec 30, 2013 at 12:45 PM, Massimiliano Tomassoli kiuhn...@gmail.com wrote: On Monday, December 30, 2013 6:27:05 PM UTC+1, Cedric Greevey wrote: On Mon, Dec 30, 2013 at 12:13 PM, Massimiliano Tomassoli kiuh...@gmail.com wrote: On Sunday, December 29, 2013 10:11:47 PM UTC+1, tbc++ wrote: Not mentioned in Cedric's post are two other important things: Protocols can be extended to existing types. For example: (defprotocol IType (type-as-string [x])) (extend-protocol IType String (type-as-string [x] string) Integer (type-as-string [x] integer)) = (type-as-string 42) integer Here we are adding new methods to sealed closed classes that already exist in the JVM. We never modify these classes, we simply extend our protocol to them. Secondly, all protocol functions are namespaced. This allows us to extend classes without fear of overwriting existing methods. This then is more powerful than monkey patching in Ruby or Python as the resulting method is more like 42.user_type-as-string(). Clojure's namespace system then allows you to refer to one method or the other just as you would any normal functions. You're not really adding methods to classes in Clojure. You're just defining external functions. Can you make them private or protected? In my opinion, the Expression Problem in FP and OOP are two different problems. In FP you can solve it more easily because you use pseudo-classes which don't behave like real classes at all. The proof of this is that any sufficiently dynamic OO language can solve the problem the same way Clojure does just by using classes with no methods and by using overloading resolved at runtime. Of course, you don't do that in OOP because you want to work with real classes. For instance, C# has extension methods which let you add methods to existing classes without any recompilation. Problem solved? I don't think so. Extension methods are just static functions that emulate the behavior of instance methods, but without any kind of encapsulation and possibility of inheritance. Encapsulation is less important without a lot of mutable state lying around, and remains important mainly at module boundaries, not class-like boundaries, where code belonging to different programmers comes into contact. If I change the internals of doohickey A and that breaks doohickey B inside the same module, I can fix B, and I know how to, and I know to do so as soon as I change A. It's when someone else changes doohickey C in a different module that I'm in trouble if I'm depending on the internals, but then hopefully there's an encapsulation boundary at the module boundary between my stuff and doohickey C. As for inheritance, it's *highly* overrated, complecting as it does composition and polymorphism. We Clojurians tend to keep those separated, and as a result protocols are purely about polymorphism while composition is dealt with in some orthogonal way. That's your opinion and I respect that. Maybe someday I'll come around to seeing things your way as I delve into Clojure, but I doubt it :) But I still think that we can't compare OOP and non-OOP languages w.r.t. the Expression Problem. If the Expression Problem consists in extending classes then non-OOP languages must be excluded because they don't have classes. We can't put datatypes and classes on the same level. They're just different things. That would then suggest that the Expression Problem is a problem that only OOP has. ;) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: protocols and overloading
On Mon, Dec 30, 2013 at 12:59 PM, Massimiliano Tomassoli kiuhn...@gmail.com wrote: On Monday, December 30, 2013 6:31:52 PM UTC+1, Cedric Greevey wrote: On Mon, Dec 30, 2013 at 12:30 PM, Massimiliano Tomassoli kiuh...@gmail.com wrote: On Sunday, December 29, 2013 11:30:16 PM UTC+1, Cedric Greevey wrote: On Sun, Dec 29, 2013 at 4:11 PM, Timothy Baldridge tbald...@gmail.comwrote: Not mentioned in Cedric's post are two other important things: Protocols can be extended to existing types. These are important for the Expression Problem, but not for the OP's query as originally stated, which simply asked for the contrast with overloading. That contrast is dynamic vs. static dispatch. As for C++ being able to solve the Expression Problem and thus being equally powerful, well, both languages are also Turing complete. But which will generally let you be more expressive, with less ceremony and verbosity? Which has templates and macros that are unhygienic and a bugbear to work with, and which has macros that are very safe and clean? What I was saying was more subtle. If C++ can solve the Expression Problem the same way Clojure does, why do you say that Clojure's solution is acceptable whereas C++ programmers don't accept the same solution for C++? That's simple: external functions are not real methods. So we're accepting Clojure's solution because Clojure doesn't support real methods and objects, but we're rejecting the same solution in C++ because C++ *does* have real methods and objects. Isn't that absurd? I think you'll need to define what you mean by real methods and objects, and in what way the word real is supposed to be establishing a contrast. A contrast with what, exactly? A class must support encapsulation, inheritance and polymorphism. If it doesn't, then it isn't a class. The same way, a method is a function that belongs to a class and can be public, private or protected. If a function is external to an object (i.e. it can't be made private or protected) than it isn't a method. I'd submit that your definition is too narrow, since it excludes quite possibly *the* most archetypal of object oriented languages. I speak, of course, of Smalltalk, which the last time I checked had classes whose fields were automatically private and methods automatically public (though you could comment that you didn't intend a method to be called by outside users -- and you can use defn- in clojure, or make this is private comments in any language that has comments or sufficiently generous limits on identifiers as to permit calling a bunch of things names like private_foo). -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Creating a CMS with Clojure(Script)
Hello. I'll be ready to give away 100 $ to help you build this project. leontalbot a gmail com. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Creating a CMS with Clojure(Script)
Thanks for the offer Leon. :) Currently I'm busy with a lot of other stuff so I can't dedicate time to this but if I ever come back to this I'll contact you. :) On Monday, December 30, 2013 3:27:27 PM UTC-6, Leon Talbot wrote: Hello. I'll be ready to give away 100 $ to help you build this project. leontalbot a gmail com. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: protocols and overloading
On Mon, Dec 30, 2013 at 11:30 AM, Cedric Greevey cgree...@gmail.com wrote: On Mon, Dec 30, 2013 at 12:59 PM, Massimiliano Tomassoli A class must support encapsulation, inheritance and polymorphism. If it doesn't, then it isn't a class. The same way, a method is a function that belongs to a class and can be public, private or protected. If a function is external to an object (i.e. it can't be made private or protected) than it isn't a method. I'd submit that your definition is too narrow, since it excludes quite possibly *the* most archetypal of object oriented languages. I speak, of course, of Smalltalk, which the last time I checked had classes whose fields were automatically private and methods automatically public Massimiliano's definition excludes several other OOP languages... :) -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
ANN: ClojureScript 0.0-2138
ClojureScript, the Clojure compiler that emits JavaScript source code. README and source code: https://github.com/clojure/clojurescript New release version: 0.0-2138 Leiningen dependency information: [org.clojure/clojurescript 0.0-2138] Enhancements: * Implement specify, instance level protocol extension for ICloneable extenders -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: ANN: Om, a ClojureScript binding to Facebook's React
On Thursday, December 19, 2013 11:12:12 AM UTC-8, David Nolen wrote: Enjoy, http://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/ David I've been playing around with some basics. I'm still a relative n00b when it comes to functional programming, and I've never looked at React before. Very cool stuff. I managed to get Om+React to display a list of items that are sorted by a given key, and I have a content-editable span which updates the state of the owner with new value of that key for a given item, and voila! the list item moves to the correct position. (as expected) Now here's the tricky part... I want to implement a drag-list, where I can drag-drop items into a new position, and update the key based on the new position. I have that algorithm working in a different project (using goog.DragListGroup) , but React does not like you to manipulate the DOM outside it's knowledge. I found this : https://groups.google.com/forum/#!searchin/reactjs/sortable/reactjs/mHfBGI3Qwz4/rXSr-1QUcKwJ which lead to http://jsfiddle.net/LQxy7/ Unfortunately, I can't get this to work with Om. I am having trouble navigating the data structures. How are props created/accessed? I followed the TodoMVC example, but that seems to be using state, which I am given to understand should be kept as high in the hierarchy as possible (per the React recommendations). I tried something like (:value (om/get-props this)) from within IRender, but that doesn't work. Also : (om/get-props this [:items] ) (following the idiom established by get-state. I'm probably missing something obvious, so I thought I'd pop in here to see if there's someone who can point me in the right direction. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: ANN: Om, a ClojureScript binding to Facebook's React
From a React dev: https://www.khanacademy.org/preview/content/items/xfa03b103 https://github.com/Khan/perseus/blob/master/src/widgets/orderer.jsx#L6-L439 I'm sure this can be adapted for Om. I may write up a simpler Om example in the future. David On Tue, Dec 31, 2013 at 12:43 AM, David Pidcock eraz0rh...@gmail.comwrote: On Thursday, December 19, 2013 11:12:12 AM UTC-8, David Nolen wrote: Enjoy, http://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/ David I've been playing around with some basics. I'm still a relative n00b when it comes to functional programming, and I've never looked at React before. Very cool stuff. I managed to get Om+React to display a list of items that are sorted by a given key, and I have a content-editable span which updates the state of the owner with new value of that key for a given item, and voila! the list item moves to the correct position. (as expected) Now here's the tricky part... I want to implement a drag-list, where I can drag-drop items into a new position, and update the key based on the new position. I have that algorithm working in a different project (using goog.DragListGroup) , but React does not like you to manipulate the DOM outside it's knowledge. I found this : https://groups.google.com/forum/#!searchin/reactjs/sortable/reactjs/mHfBGI3Qwz4/rXSr-1QUcKwJ which lead to http://jsfiddle.net/LQxy7/ Unfortunately, I can't get this to work with Om. I am having trouble navigating the data structures. How are props created/accessed? I followed the TodoMVC example, but that seems to be using state, which I am given to understand should be kept as high in the hierarchy as possible (per the React recommendations). I tried something like (:value (om/get-props this)) from within IRender, but that doesn't work. Also : (om/get-props this [:items] ) (following the idiom established by get-state. I'm probably missing something obvious, so I thought I'd pop in here to see if there's someone who can point me in the right direction. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
