I have posted a file (http://www.goland.org/sellorrent.pdf) which
explains the math behind the calculator. The file gives all the
algebra needed to implement the calculator. At the moment I'm just
taking the boneheaded approach and implementing all the logic in
Clojure as more or less a one to one mapping of the functions in the
PDF file.
Please, please, please, keep in mind that the linked article is a very
rough, rough draft. It is not ready for prime time. I am only sharing
it so that you can see what I'm trying to implement and hopefully
guide me to the right way to implement it.
It seems however that the consensus of the group based on what I've
said so far is to pass around state in a structmap. This is nice in
that it makes each function completely self contained (e.g. no
external references). It's unfortunate in that it now means that every
single function needs this extra argument and every variable access
either needs to use the :keys feature in the arguments or has to
directly refer to the keys in the map.
I really wish there was a way for me to just declare a context, define
a bunch of statics and then define all my methods inside of that
context. But it doesn't seem like this is the clojure way of handling
the problem. Where as many aspects of functional programming make a
ton of sense to me having to carry a map around everywhere doesn't
seem like an advantage. But I'm probably just missing something.
Yaron
On Feb 16, 1:20 pm, Richard Newman <holyg...@gmail.com> wrote:
> > For the method tax_deductible_expenses to run it ends up requiring 19
> > user defined values. That's a whole lot of arguments to pass into a
> > function. Obviously I could wrap them up in a StructMap but then I get
> > expressions like (+ 1 (args :B)) which doesn't seem much better than
> > (+1 (B)).
>
> Pass them in as a map, and destructure at the start of the function:
>
> (defn tax-deductible-expenses [{:keys [management-fee
> tenant-finding-fee ...]}]
> ...)
>
> > The issue I'm really trying to put my finger on is - these arguments
> > really and truly are 'constants' within the context of the calculator.
> > But they are constants whose values are not known as compile time but
> > rather are known at run time.
>
> That they're "constant" does not mean that you shouldn't pass them as
> arguments to your functions.
>
> Most values obtained from users or config files are such "run-time
> constants". Heck, many values in most programs are -- "HTTP listener
> port", "log file location", etc.
>
> You still invoke your HTTP server with a :port argument.
>
> Indeed, the more fixed values you have, the less likely it is that you
> should define a var for each. Maybe one var containing a map, but I'd
> still pass the map around rather than having each function implicitly
> refer to it. It makes testing easier.
>
> > Does Clojure have a way to express a
> > 'late bound' constant or is the 'right' solution to pass around 19+
> > arguments to functions or passing around StructMaps or making
> > everything into thunks?
>
> The reason you pass them around as arguments is so that the behavior
> of your functions is precisely determined *only* by its arguments --
> they are pure.
>
> That means that you can memoize them, easily write tests for them,
> have them work correctly when part of a lazy sequence (which will
> often be evaluated outside the scope of your bindings), etc.
>
> For example: how would you compare the tax-deductible-expenses of two
> clients? You'd need to invoke the function twice, with a huge nest of
> bindings around each call. Much better would be to store the
> appropriate values in two maps, then say
>
> (< (tax-deductible-expenses 0 john-data)
> (tax-deductible-expenses 0 bill-data))
>
> -R
--
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
