For anybody who's still following, I've updated accessors.clj with a new
behavior. I realized assoc-in and get-in are very powerful, they work with
all sorts of collections (not just maps, duh on my part), thus now
if anything in the list of accessor symbols is not actually a
clojure.lang.Symbol, i
GENIOUS idea Laurent ;)
Extremely terse and uniform. Also because I switched the implementation to
use multimethods, performance has jumped quite a bit. In fact if you memoize
find-accessors, the code is only a little bit slower than
update-in/assoc-in/get-in! The defset and defget macros now check
Hello,
Maybe you should consider creating a single function with 2 arities:
with one argument, it's the getter, with two arguments, it's the
setter (that returns the new type) !
(prop-foo obj) ; --> returns the property prop-foo
(prop-foo obj newval) ; --> returns a new version of obj with prop
You're right. The following includes code for handling this case via setin
and getin. I've also ditched macros, because that code couldn't support new
lexical scopes in the setter/getter definition. setin getin support works by
dynamically resolving getters and setters, thus this is slower than dir
It's worth considering how *nested* accessors would work in the
context of immutability.
The nested maps approach works really nicely, due in part to functions
like assoc-in:
; From Mark Volkmann's tutorial
(assoc-in person [:employer :address :city] "Clayton")
What would the above update look
You have some valid points, but I think trying to come up with a solution
using existing components in Clojure in order to determine if there really
is a gap in Clojure's design is the best approach. I don't always use
accessor macros but that's because I don't normally build up maps that are
inten
On Fri, Apr 24, 2009 at 3:36 PM, David Nolen wrote:
> Is this really so hard?
Are you telling me that you routinely write accessors for all your
data structures in Clojure using those macros? I'll bet very few
people do this. People make use of the facilities conveniently
available to them. U
Perhaps I'm being dense but I still fail to see what the issue is here:
(defn setter [sym]
`(defn ~(symbol (str "set-" sym)) [~'x ~'y]
(assoc ~'x ~(keyword (str sym)) ~'y)))
(defn getter [sym]
`(defn ~(symbol (str "get-" sym)) [~'x]
(~(keyword (str sym)) ~'x)))
(defmacro accessors [
Laurent, I think we're actually mostly in agreement here, although we
differ on some of the details.
I agree with the Principle of Uniform Access. One interpretation of
this principle is that coders should never have a public field, and
should always use getters and setters, to make the API futu
Oops didn't finish my thought before sending. Anyways, the point is that
Clojure encourages the programmer to design functionality around functions
not data structures. Because Clojure is a Lisp, this syntax can be very
expressive.
On Fri, Apr 24, 2009 at 12:49 PM, David Nolen wrote:
> On Fri, Apr
On Fri, Apr 24, 2009 at 12:15 PM, Mark Engelberg
wrote:
>
> The problem, of course, is that there is a language design principle
> that has evolved in the OO community that client code shouldn't need
> to know whether you are accessing a field or a method. In Clojure,
> things kind of break down
2009/4/24 Mark Engelberg :
>
> On Fri, Apr 24, 2009 at 2:21 AM, AndrewC. wrote:
>> If client code is using assoc and get then you haven't really started
>> thinking of your map as a new data type - you're still thinking of it
>> as a map.
>
> I disagree with this assertion, and the comparison to
On Fri, Apr 24, 2009 at 2:21 AM, AndrewC. wrote:
> If client code is using assoc and get then you haven't really started
> thinking of your map as a new data type - you're still thinking of it
> as a map.
I disagree with this assertion, and the comparison to the SICP
example. Unlike Scheme, Clo
2009/4/24 Mark Reid :
>
> Hi,
>
> This is probably digressing a little from the original question but I
> was wondering if using namespaces here is a reasonable thing to do
> when designing ADTs.
>
>> SICP tells us that we should be defining accessor functions
>> immediately when we create a new d
Hi,
This is probably digressing a little from the original question but I
was wondering if using namespaces here is a reasonable thing to do
when designing ADTs.
> SICP tells us that we should be defining accessor functions
> immediately when we create a new data type.
>
> (defn make-fraction [n
2009/4/24 AndrewC. :
>
>
>
> On 23 Apr, 17:59, Mark Engelberg wrote:
>> Another problem that has already been "solved" by many OO languages is
>> that initially it is most convenient to code certain things as
>> properties of the object, and somewhere down the line, you may want to
>> change prop
On 23 Apr, 17:59, Mark Engelberg wrote:
> Another problem that has already been "solved" by many OO languages is
> that initially it is most convenient to code certain things as
> properties of the object, and somewhere down the line, you may want to
> change property access into a method call.
On Apr 23, 2009, at 18:59, Mark Engelberg wrote:
> Konrad has written a library that turns equality into a multimethod.
> This provides the hooks for altering equality for maps, but there are
> a lot of questions in my mind about how well this will coexist with
> other Clojure code and just how s
In Clojure, the closest thing to an object (short of implementing a
class in Java or using gen-class) is the map. But the more I play
around with using maps to implement the kinds of things that objects
are used for in other languages, the more I'm feeling that maps don't
quite cut it.
One probl
; >> > (get-private my-object :first) ; -> "Bob"
> >> > (= my-object my-other-object) ; -> true
> >> > No secret keys, no other libraries, and I believe this supports
> equality
> >> > just fine. Since we're u
-object my-other-object) ; -> true
>> > No secret keys, no other libraries, and I believe this supports equality
>> > just fine. Since we're using metadata the data travels around easily
>>
>> This won't work, since metadata is not used for equal
ust fine. Since we're using metadata the data travels around easily
>
> This won't work, since metadata is not used for equality tests, isn't
> that right?
>
> Regards,
>
> Victor Rodriguez.
>
> > between operations.
> > -- Forwarded m
ries, and I believe this supports equality
> just fine. Since we're using metadata the data travels around easily
This won't work, since metadata is not used for equality tests, isn't
that right?
Regards,
Victor Rodriguez.
> between operations.
> -- Forwarded m
On Apr 21, 11:41 am, Mark Engelberg wrote:
> On Mon, Apr 20, 2009 at 11:00 AM, Timo Mihaljov wrote:
> > Is the concept of Abstract Data Types [1] useful in Clojure?
>
> > If yes, how would you implement one?
>
> I have composed a lengthy response to this question, and added it to my
> blog:http
operations.
> ------ Forwarded message --
> From: Mark Engelberg
> Date: Tue, Apr 21, 2009 at 6:41 AM
> Subject: Re: Abstract data types in functional languages
> To: clojure@googlegroups.com
>
>
>
> On Mon, Apr 20, 2009 at 11:00 AM, Timo Mihaljov wrote:
>>
ween operations.
-- Forwarded message --
From: Mark Engelberg
Date: Tue, Apr 21, 2009 at 6:41 AM
Subject: Re: Abstract data types in functional languages
To: clojure@googlegroups.com
On Mon, Apr 20, 2009 at 11:00 AM, Timo Mihaljov wrote:
> Is the concept of Abstract Data Types [1] usefu
On Mon, Apr 20, 2009 at 11:00 AM, Timo Mihaljov wrote:
> Is the concept of Abstract Data Types [1] useful in Clojure?
>
> If yes, how would you implement one?
I have composed a lengthy response to this question, and added it to my blog:
http://programming-puzzler.blogspot.com/2009/04/adts-in-clo
On 20.04.2009, at 20:00, Timo Mihaljov wrote:
> Is the concept of Abstract Data Types [1] useful in Clojure?
Yes, although the abstraction is necessarily leaky in that you cannot
enforce it in the absence of static typing.
> If yes, how would you implement one?
Like in any other language: by
Konrad added an early implementation of abstract data types to
clojure-contrib (types.clj) you might want to check that out.
I also did some work on supporting more traditional style OO with Spinoza
(structural+behavioral inheritance), but I've sidelined it for the time
being until I find that I ac
I think Konrad's and David's replies confirm my suspicion that I'm
trying to find a solution to a problem that one does not encounter in
Clojure. This makes my example irrelevant and a poor context for the
discussion, so I'm changing the subject and bombard you with a new set
of newbie questions.
30 matches
Mail list logo
