Hm, the most common way to encapsulate in clojure is with a closure:
Your account repository would be:
(defn account-repository [connection]
;; <- here goes additional constructor logic
(fn save [account]
(sql-save connection account))
If the repository has more methods than just save, y
I wouldn't get too hung up on imitation as whilst there are style
guides [1] I you will find a lot of diversity in "published" Clojure
code.
I would suggest you internalise the style guide, lean on "lein kibit"
and "lein eastwood" and then do some navel gazing and ask yourself
what problem you are
Yeah, it wouldn't surprise me if I'm over thinking it too much. But in the
model of 'shu-ha-ri' I am still very much in the shu stage so i'm looking
for concrete stuff to imitate. :)
Thank you everyone for the ideas and thoughts,
-d
On Saturday, February 7, 2015 at 10:23:43 AM UTC-6, Dru Sell
Thank you everyone for all of the helpful ideas.
I def like the Component library and I will have to sit down and figure out
how to best work that into my application while it is still young.
All of the links have been consumed and I am starting to absorb more and
more. Thank you for taking the
@Dru, I feel I'm ahead of you in learning Clojure, but I'm not yet to where
@Colin is. However, I'm close enough that I recognize how accurate and
concise his advice is--in fact, I'm saving it to remind myself!
Also, I just finished reading Functional Programming Patterns in Scala and
Clojure,
If you find yourself passing the same argument over and over, you can
always work in a partial:
(def save-account (partial save db))
On Sunday, February 8, 2015 at 6:47:29 PM UTC+1, Colin Yates wrote:
>
> I missed the salient point about data transformations which is that of
> abstractions. In
On Feb 8, 2015, at 6:42 PM, David James wrote:
> I often group functions that operate on similar data structures together in a
> namespace. This isn't always clear-cut, because some functions may "fit" in
> more than one namespace. I sometimes use a (soft) convention to group
> functions by the
I often group functions that operate on similar data structures together in
a namespace. This isn't always clear-cut, because some functions may "fit"
in more than one namespace. I sometimes use a (soft) convention to group
functions by the first argument. Yes, this means that my Clojure project
I missed the salient point about data transformations which is that of
abstractions. In OO (Java at least) almost everything was a special case,
in Clojure it is the polar opposite; almost nothing is a special case.
It is astonishing how many domains can be sufficiently modeled as a
sequence o
+1 This separation of behaviour and state is a key part of Clojure's
philosophy. That isn't to say that stateful components are bad as such
(Stuart Sierra's https://github.com/stuartsierra/component is an
obvious analog here) only that they aren't a given as they are in OO
languages.
As Jony says,
When I first came to Clojure (from C# of all things), I had questions like
this too. But over time I've become convinced that it was something I
worried to much about. The guiding rule for code organization should be
this: does it slow you down from the complexity? Are there so many files,
that you
To put take a different angle on it: you might soon get to *like* that it's
usual to pass in everything as a parameter explicitly. It has the advantage
that it's easy to reason about what a function does just by looking at the
function. In the example above, when reading AccountRepository.Save y
Hi Dru,
I find it easier to organize things when I follow TDD. It's easier for me
to spot something is in the wrong place (module or maybe as a
responsibility of a function) by looking at the tests. (This is true for
any language I work with.)
http://butunclebob.com/ArticleS.UncleBob.TheThreeRule
I think there's less difference than you imagine. In C# you might write:
repository.Save(account)
Whereas in Clojure:
(save repository account)
The parameter lists are wider in Clojure only because Clojure doesn't have
an explicit method call syntax.
- James
On 7 February 2015 at 16:0
The real challenge is to reconceptualize your problem domain into a
non-destructive framework.
In other words, you need to transform your way of thinking from:
move function (or method) takes a Shape and destructively updates the
shape's x and y, returning void
to
move function takes a Shape and re
Very cool.
On Wed, Apr 1, 2009 at 8:47 AM, Rich Hickey wrote:
>
>
> I've added get-method (SVN 1338).
>
> (derive ::Circle ::Shape)
> (derive ::Rect ::Shape)
>
> (defmulti area :Shape)
>
> ;note - you can name methods
> (defmethod area ::Shape area-shape [x] nil)
>
> (get-method area ::Rect)
> #
On Apr 1, 2009, at 14:47, Rich Hickey wrote:
> I've added get-method (SVN 1338).
Great, thanks!
> Note how you can name methods for diagnostic purposes. This doesn't
> introduce names into the namespace, just puts a name on the fn object.
It's also useful for recursive calls, if you are sure y
On Mar 31, 12:45 pm, Konrad Hinsen wrote:
> On Mar 31, 2009, at 16:32, Rich Hickey wrote:
>
> > Here are some problems/limitations of existing OO/GF systems that I
> > don't intend to repeat:
>
> ...
>
> I agree that these are not desirable features. I have had to work
> around some of them man
On 31.03.2009, at 21:48, Konrad Hinsen wrote:
> On 31.03.2009, at 18:50, Mark Engelberg wrote:
>
>> On Tue, Mar 31, 2009 at 9:45 AM, Konrad Hinsen
>> wrote:
>>> I think this should be sufficient to cover all cases you mentioned,
>>> but of course it needs to be tried in practice.
>>
>> I think y
On Mar 31, 2:25 pm, Rich Hickey wrote:
> On Mar 31, 2:18 pm, mikel wrote:
> What about predicate, or rule based dispatch - why hardwire the notion
> of types, traversal or matching?
Those are different names for the same pieces.
> This is simply an exhausting amount of talk - how about a p
On 31.03.2009, at 18:50, Mark Engelberg wrote:
> On Tue, Mar 31, 2009 at 9:45 AM, Konrad Hinsen
> wrote:
>> I think this should be sufficient to cover all cases you mentioned,
>> but of course it needs to be tried in practice.
>
> I think your idea of specifying a sequence of items to try in the
On Mar 31, 2:18 pm, mikel wrote:
> On Mar 31, 11:45 am, Konrad Hinsen wrote:
>
>
>
> > On Mar 31, 2009, at 16:32, Rich Hickey wrote:
>
> > > Here are some problems/limitations of existing OO/GF systems that I
> > > don't intend to repeat:
>
> > ...
>
> > I agree that these are not desirable fe
On Mar 31, 11:45 am, Konrad Hinsen wrote:
> On Mar 31, 2009, at 16:32, Rich Hickey wrote:
>
> > Here are some problems/limitations of existing OO/GF systems that I
> > don't intend to repeat:
>
> ...
>
> I agree that these are not desirable features. I have had to work
> around some of them man
On Tue, Mar 31, 2009 at 9:45 AM, Konrad Hinsen
wrote:
> I think this should be sufficient to cover all cases you mentioned,
> but of course it needs to be tried in practice.
I think your idea of specifying a sequence of items to try in the
dispatching function, at the point of definition for the
On Mar 31, 2009, at 16:32, Rich Hickey wrote:
> Here are some problems/limitations of existing OO/GF systems that I
> don't intend to repeat:
...
I agree that these are not desirable features. I have had to work
around some of them many times in the past. Traditional OO combines
aspects that
Many thanks for the long and reasoned reply (and to mikel as well for adding
his thoughts). I apologize for my slowness in understanding the nature of
multimethods- it's tricky converting my existing knowledge ;)
On Tue, Mar 31, 2009 at 10:32 AM, Rich Hickey wrote:
>
>
> Here are the areas I'm lo
Hi,
2009/3/31 Rich Hickey
> Here's how I think about it:
>
> - Hierarchies have nothing to do with multimethods/GFs per se.
True,
So, along the lines of my previous post, could it be made possible to let
the user provide its own multimethods "candidate dispatch-values filtering"
and "candidat
On Mar 31, 9:32 am, Rich Hickey wrote:
> Can we please move forward in trying to implement something better
> than CLOS GFs?
Maybe. Let me know when you think of something better, and I'll do the
same. When we agree, I'll toss my GF implementation out the door. In
the meantime, it's made my
Here are some problems/limitations of existing OO/GF systems that I
don't intend to repeat:
A) They provide only a single declaration point for all superclasses
of a class
B) They consider the local declaration order of superclasses to be
significant
C) They conflate hierarchies and graphs contai
On Mar 29, 8:08 am, Meikel Brandmeyer wrote:
> Hi,
>
> Am 27.03.2009 um 09:25 schrieb Mark Engelberg:
>
>
>
> > I may come along and want to extend test-prefer to a type ::d which
> > derives from ::c and ::e, where ::e provides an alternative
> > implementation.
>
> > ab
On Mar 28, 6:30 pm, David Nolen wrote:
> Having thought a little about multiple inheritance when implementing Spinoza
> I also ran into this problem. However at the time I wasn't hindered by
> multifn dispatch as much as the fact that parents cannot be ordered (because
> calling parents on a ta
On Mar 30, 2009, at 0:16, mikel wrote:
> Sure, that's right. Maybe constructing such a value in the first place
> is an error.
I'd say so. If it were up to me to provide a fix for the situation
you describe, I'd fix proxy to make it impossible to create an object
that doesn't implement the i
On Mar 29, 4:40 pm, David Nolen wrote:
> I see, thanks for the clarification. It does seem like you are purposefully
> creating a situation in which type will fail since something more likely:
> (type (proxy [clojure.lang.IRef][]))
>
> works fine.
>
> I'm wondering if a CLOS-like system would r
On Mar 29, 7:22 am, Konrad Hinsen wrote:
> On 29.03.2009, at 07:25, mikel wrote:
>
> >> Enjoying the thread. Out of curiosity for which Clojure values is
> >> the return
> >> value of the type function undefined?
>
> > Try this:
>
> > (type (proxy [clojure.lang.IMeta clojure.lang.IRef][]))
>
I see, thanks for the clarification. It does seem like you are purposefully
creating a situation in which type will fail since something more likely:
(type (proxy [clojure.lang.IRef][]))
works fine.
I'm wondering if a CLOS-like system would really have to handle such a
degenerate (in the technica
On Mar 29, 1:34 am, David Nolen wrote:
> On Sun, Mar 29, 2009 at 1:25 AM, mikel wrote:
>
> > (type (proxy [clojure.lang.IMeta clojure.lang.IRef][]))
>
> > java.lang.UnsupportedOperationException: meta (NO_SOURCE_FILE:0)
> > [Thrown class clojure.lang.Compiler$CompilerException]
>
> > No doubt
On 29.03.2009, at 07:25, mikel wrote:
>> Enjoying the thread. Out of curiosity for which Clojure values is
>> the return
>> value of the type function undefined?
>
> Try this:
>
> (type (proxy [clojure.lang.IMeta clojure.lang.IRef][]))
>
> java.lang.UnsupportedOperationException: meta (NO_SOURC
Hi,
Am 27.03.2009 um 09:25 schrieb Mark Engelberg:
I may come along and want to extend test-prefer to a type ::d which
derives from ::c and ::e, where ::e provides an alternative
implementation.
ab (a and b are intended to be hidden from
end-user)
| |
-
Hi,
Am 29.03.2009 um 08:34 schrieb David Nolen:
Not totally following you here as:
(proxy [clojure.lang.IMeta clojure.lang.IRef][])
immediately throws an error. I can't think of a situation in Clojure
where the type function does not return a usable value. Let me know
if I'm wrong, but yo
On Sun, Mar 29, 2009 at 1:25 AM, mikel wrote:
>
> (type (proxy [clojure.lang.IMeta clojure.lang.IRef][]))
>
> java.lang.UnsupportedOperationException: meta (NO_SOURCE_FILE:0)
> [Thrown class clojure.lang.Compiler$CompilerException]
>
>
> No doubt someone is going to point out that the proxy objec
On Mar 28, 4:28 pm, David Nolen wrote:
> On Sat, Mar 28, 2009 at 4:40 PM, mikel wrote:
>
> > So, at minimum, to make a solid port, you need to add a function that
> > can return a sensible type value for any input
>
> Enjoying the thread. Out of curiosity for which Clojure values is the return
Having thought a little about multiple inheritance when implementing Spinoza
I also ran into this problem. However at the time I wasn't hindered by
multifn dispatch as much as the fact that parents cannot be ordered (because
calling parents on a tag returns a set) as pointed out by Mark. I understa
On Sat, Mar 28, 2009 at 4:40 PM, mikel wrote:
>
> So, at minimum, to make a solid port, you need to add a function that
> can return a sensible type value for any input
Enjoying the thread. Out of curiosity for which Clojure values is the return
value of the type function undefined?
David
--~
On Mar 28, 4:22 am, Michael Wood wrote:
> On Thu, Mar 26, 2009 at 12:49 PM, Marko Kocić wrote:
>
> > On 25 мар, 21:41, mikel wrote:
> >> Tinyclos is decent, and lots of people have made good use of it. For
> >> example, it's a "standard" extension to Chicken Scheme (insofar as
> >> anything t
On Thu, Mar 26, 2009 at 12:49 PM, Marko Kocić wrote:
>
> On 25 мар, 21:41, mikel wrote:
>> Tinyclos is decent, and lots of people have made good use of it. For
>> example, it's a "standard" extension to Chicken Scheme (insofar as
>> anything to do with Chicken Scheme can be called "standard") an
On Mar 25, 3:44 am, Konrad Hinsen wrote:
> I haven't thought much about extending types yet. It could mean
> opening the can of worms associated with inheritance and all that. I
> am waiting for a concrete situation where extension would be useful
> to think about how best to do it.
The
On Fri, Mar 27, 2009 at 4:58 PM, mikel wrote:
>
>
>
> On Mar 27, 5:56 am, Konrad Hinsen wrote:
>> On Mar 27, 2009, at 9:25, Mark Engelberg wrote:
>
>> > Considering how complex the situation can get with single dispatch, I
>> > imagine it gets even more complex in multiple dispatch situations.
On Mar 27, 5:56 am, Konrad Hinsen wrote:
> On Mar 27, 2009, at 9:25, Mark Engelberg wrote:
> > Considering how complex the situation can get with single dispatch, I
> > imagine it gets even more complex in multiple dispatch situations. In
> > the multimethods example at clojure.org/multimetho
2009/3/27 Konrad Hinsen
>
> On the other hand, I would definitely like to be able to implement
> left-to-right precedence myself on top of Clojure's multimethods, and
> it seems that at the moment this is not possible.
Yes.
And also the ability to redefine the method that tries to determine
ca
On Mar 27, 2009, at 9:25, Mark Engelberg wrote:
> I think I've answered at least part of my own question. This is the
> simplest ambiguous case I've found:
>
> ab
> | |
> --
> |
> c
Indeed. An ambiguous situation can occur whenever the type hierarchy
graph is n
I think I've answered at least part of my own question. This is the
simplest ambiguous case I've found:
ab
| |
--
|
c
user> (defmulti test-prefer :tag)
#'user/test-prefer
user> (defmethod test-prefer ::a [h] "a")
#
user> (defmethod test-prefer ::b [h] "b")
#
user
I'm very interested in this thread. I'm having trouble figuring out
exactly which situations require prefer-method and which do not. One
thing that would help me understand the issues more deeply would be if
someone could post the simplest possible multimethod that requires
prefer-method to disa
2009/3/26 Konrad Hinsen
>
> On 26.03.2009, at 14:59, Rich Hickey wrote:
>
> > Plus the inability to dispatch on other than class or eql, the
> > inability to superimpose another taxonomy without redefining the
> > class, the inability to have multiple independent taxonomies...
>
> The ability to
On Mar 26, 8:59 am, Rich Hickey wrote:
> On Mar 25, 6:47 am, mikel wrote:
[...my misgivings snipped...]
> I wonder about the generality of this concern. Defining new methods
> that break existing code implies both defining new methods on existing
> super-types *and* some crosscutting multipl
On 26.03.2009, at 14:59, Rich Hickey wrote:
> Plus the inability to dispatch on other than class or eql, the
> inability to superimpose another taxonomy without redefining the
> class, the inability to have multiple independent taxonomies...
The ability to have multiple taxonomies is indeed very
On Mar 25, 6:47 am, mikel wrote:
> On Mar 25, 4:13 am, Mark Engelberg wrote:
>
> > On Wed, Mar 25, 2009 at 1:44 AM, Konrad Hinsen
>
> > wrote:
> > > Could you elaborate a bit on this? I haven't met any major obstacles
> > > with multimethods yet. The dispatch functions give quite a lot of
> >
On 25 мар, 21:41, mikel wrote:
> Tinyclos is decent, and lots of people have made good use of it. For
> example, it's a "standard" extension to Chicken Scheme (insofar as
> anything to do with Chicken Scheme can be called "standard") and has
> lots of enhancements provided by Felix.
I'll take
On Mar 25, 2:51 pm, Marko Kocić wrote:
> Does anybody know of some minimal clos implementation that is easily
> portable?
>
> I suppose that it contain base functions that are implemented in CL,
> and the rest of clos built on top of that.
> It might be interesting to try to adapt such a librar
On Mar 25, 12:35 pm, Konrad Hinsen wrote:
> On 25.03.2009, at 10:13, Mark Engelberg wrote:
>
> > 1. Structs don't inherently have a type. If you want to dispatch on
> > type (a common use-case), you have to make a constructor that inserts
> > the type information as part of the struct. Some h
Does anybody know of some minimal clos implementation that is easily
portable?
I suppose that it contain base functions that are implemented in CL,
and the rest of clos built on top of that.
It might be interesting to try to adapt such a library to clojure.
I remember people mentioning PCL and c
On 25.03.2009, at 10:13, Mark Engelberg wrote:
> 1. Structs don't inherently have a type. If you want to dispatch on
> type (a common use-case), you have to make a constructor that inserts
> the type information as part of the struct. Some have expressed
And/or in the metadata.
> concern that
On Mar 25, 4:13 am, Mark Engelberg wrote:
> On Wed, Mar 25, 2009 at 1:44 AM, Konrad Hinsen
>
> wrote:
> > Could you elaborate a bit on this? I haven't met any major obstacles
> > with multimethods yet. The dispatch functions give quite a lot of
> > flexibility in practice. In what situation di
On Wed, Mar 25, 2009 at 1:44 AM, Konrad Hinsen
wrote:
> Could you elaborate a bit on this? I haven't met any major obstacles
> with multimethods yet. The dispatch functions give quite a lot of
> flexibility in practice. In what situation did you find them
> inconvenient?
To summarize, I think th
On 24.03.2009, at 19:29, mikel wrote:
> I personally like Haskell's philosophy in this area: there is a
> facility for defining data layouts, and there is a facility for
> defining protocols, and they are completely separate. You can define a
I like that as well, and I have been trying to do som
On Mar 24, 12:58 pm, Raoul Duke wrote:
> question: what do people think about the general topic of inheritance?
> my take on it so far is that inheritance apparently sounds like a good
> idea at first to some folks, but quickly turns into something of a
> nightmare if one is actually concerned
question: what do people think about the general topic of inheritance?
my take on it so far is that inheritance apparently sounds like a good
idea at first to some folks, but quickly turns into something of a
nightmare if one is actually concerned with keeping a coherent
semantics (so that (a) peo
66 matches
Mail list logo
