On Mon, 20 Apr 2009 21:53:41 +0200
Laurent PETIT wrote:
>
> Hi David,
>
> 2009/4/20 David Nolen :
> > A couple of things. In your initial example, you conflated some
> > things. One issue is simply a matter of convenience- defining a
> > getter so that you can use Python object property access
On Apr 20, 2:17 pm, Mark Engelberg wrote:
> On Mon, Apr 20, 2009 at 1:27 PM, Bradbev wrote:
> > If you promise that
> > functions will accept and return maps with certain keys, then you must
> > keep that promise moving forward.
>
> I think you're missing part of the point of the original post.
On Apr 20, 4:17 pm, Mark Engelberg wrote:
> On Mon, Apr 20, 2009 at 1:27 PM, Bradbev wrote:
> > If you promise that
> > functions will accept and return maps with certain keys, then you must
> > keep that promise moving forward.
>
> I think you're missing part of the point of the original post
On Mon, Apr 20, 2009 at 1:27 PM, Bradbev wrote:
> If you promise that
> functions will accept and return maps with certain keys, then you must
> keep that promise moving forward.
I think you're missing part of the point of the original post. You
don't really want to promise that your functions
I read the rest of this thread, and thought I'd throw in my two cents.
It seems to me that you are mostly concerned with being able to
provide a stable external API to clients while allowing the internal
data structures to change. As a library designer you need to choose
which parts of your API a
Hi David,
2009/4/20 David Nolen :
> A couple of things. In your initial example, you conflated some things. One
> issue is simply a matter of convenience- defining a getter so that you can
> use Python object property access (via the dot operator). Personally I don't
> like this idiom at all (you
On Apr 20, 12:32 pm, Laurent PETIT wrote:
> I think you Timo ask here a very interesting and important question.
>
> It's not just about having encapsulation or not. It's really about designing
> the code so that the library internals can evolve without impact on the user
> part.
In general, Lis
A couple of things. In your initial example, you conflated some things. One
issue is simply a matter of convenience- defining a getter so that you can
use Python object property access (via the dot operator). Personally I don't
like this idiom at all (you find it in Objective-C 2.0 and Javascript).
On Apr 20, 2009, at 18:13, Timo Mihaljov wrote:
> To put it another way, any answer involving custom support code (new
> macros or the like) is not the one I'm looking for. Being able to
> modify
> the language is very cool, but not being able to solve a simple
> problem
Macros are not "modi
I think you Timo ask here a very interesting and important question.
It's not just about having encapsulation or not. It's really about designing
the code so that the library internals can evolve without impact on the user
part.
Given that no "here is the standard clojure way" was called :
* ei
Matt Clark wrote:
> Maybe I'm missing something, but what is wrong with Stuart Sierra's
> solution? I quite like it, and it would probably be more appealing if
> it were encapsulated into a macro.
Frankly, it seemed like a good answer to the wrong question [1] instead
of being a recurring and wi
Laurent PETIT wrote:
> To simplify a little bit (both from a library implementor and user
> perspective), why not get rid of the appended dash - ?
>
> Indeed, having an appended dash suggests to me (so it's not apparent
> from the examples) that the user will have to access, for a same object,
Maybe I'm missing something, but what is wrong with Stuart Sierra's
solution? I quite like it, and it would probably be more appealing if
it were encapsulated into a macro.
(def-propholder person)
(def me (person {:name "Matt Clark"}))
(def-propholder person2
:name
{:getter (fn [record]
Hi again,
2009/4/20 Timo Mihaljov
>
> Laurent PETIT wrote:
> > What do others think about these 2 above statements ?
> >
> > The standard OO approach to information hiding would be private
> fields
> > and accessor methods. Any suggestions for the One True Clojure
> Pattern
> > that
Laurent PETIT wrote:
> What do others think about these 2 above statements ?
>
> The standard OO approach to information hiding would be private fields
> and accessor methods. Any suggestions for the One True Clojure Pattern
> that addresses the same problem?
>
>
> I think accessor
Hi,
2009/4/20 Timo Mihaljov
>
> Laurent PETIT wrote:
> > While interesting, this approach seems to me limited to simple cases :
> > * limited in possibilities: you are not able to directly use values of
> > other fields. So in more complex cases, you won't be able to combine
> > calculated valu
Laurent PETIT wrote:
> While interesting, this approach seems to me limited to simple cases :
> * limited in possibilities: you are not able to directly use values of
> other fields. So in more complex cases, you won't be able to combine
> calculated values without code repetition or preprarati
Hi,
Am 20.04.2009 um 08:32 schrieb Timo Mihaljov:
After a bit of googling I found what seems to be the perfect solution:
http://kotka.de/projects/clojure/lazy-map.html
(defn new-person [first-name last-name]
(lazy-struct-map person
:first-name first-name :last-name last-na
Hi,
2009/4/20 Timo Mihaljov
>
> Timo Mihaljov wrote:
> > I'm wondering about how to change a data structure without breaking the
> > API used to access it. For example, let's assume that I have a library
> > for dealing with records of people and I'm storing them in structs.
> >
> > (defstru
Timo Mihaljov wrote:
> I'm wondering about how to change a data structure without breaking the
> API used to access it. For example, let's assume that I have a library
> for dealing with records of people and I'm storing them in structs.
>
> (defstruct person :name)
>
> The users of my libra
On Apr 19, 4:00 pm, Timo Mihaljov wrote:
> What's the idiomatic Clojure way of dealing with this issue?
I'd be tempted to use accessor functions, like:
(defn get-name [person]
(:name person))
When the data structure changes, I update the function:
(defn get-name [person]
(str (:fi
On Apr 19, 11:00 am, Timo Mihaljov wrote:
> I'm wondering about how to change a data structure without breaking the
> API used to access it. For example, let's assume that I have a library
> for dealing with records of people and I'm storing them in structs.
>
> (defstruct person :name)
>
>
Hi,
I'm wondering about how to change a data structure without breaking the
API used to access it. For example, let's assume that I have a library
for dealing with records of people and I'm storing them in structs.
(defstruct person :name)
The users of my library access the data stored in
23 matches
Mail list logo
