On May 22, 9:51 pm, Pedro Teixeira pedr...@gmail.com wrote:
On Apr 27, 9:45 am, Rich Hickey richhic...@gmail.com wrote:
On Apr 27, 2010, at 3:20 AM, Mark Engelberg wrote:
Watching Stuart's tutorial, it looks like the automaticfactory
functions for deftypes have gone away (I'm
On Apr 27, 9:45 am, Rich Hickey richhic...@gmail.com wrote:
On Apr 27, 2010, at 3:20 AM, Mark Engelberg wrote:
Watching Stuart's tutorial, it looks like the automaticfactory
functions for deftypes have gone away (I'm still working with Clojure
1.1, so haven't had a chance to try the
Watching Stuart's tutorial, it looks like the automatic factory
functions for deftypes have gone away (I'm still working with Clojure
1.1, so haven't had a chance to try the latest changes for myself).
I'm going to miss that feature, especially for defrecord, which is now
the common case
On 27 Apr 2010, at 09:20, Mark Engelberg wrote:
I understand that you can always do Foo. to construct a Foo record,
but these constructors don't act as full-fledged functions, right?
No. They are not first-class objects (in fact, not objects at all in
the JVM sense), so you can't pass them
On Apr 27, 2010, at 3:20 AM, Mark Engelberg wrote:
Watching Stuart's tutorial, it looks like the automatic factory
functions for deftypes have gone away (I'm still working with Clojure
1.1, so haven't had a chance to try the latest changes for myself).
I'm going to miss that feature,
On 27.04.2010, at 14:45, Rich Hickey wrote:
I agree. I asked for suggestions for the factory fn in #clojure, but got some
pushback against introducing things in the namespace. I'm still open to
suggestions, here are the issues:
The generated type name is now imported, so at the very least
On Apr 23, 2010, at 11:48 PM, Mark Engelberg wrote:
A few meandering observations:
I like the latest change to include a this argument. It makes the
number of arguments line up which is a good thing.
I like the idea of defrecord for the common case, rather than having
to request default
On Apr 24, 2010, at 1:11 PM, Richard Newman wrote:
Neither of those attributes reveal information about the
implementation of the objects in question. They both reveal
information about the state that some client could find useful. They
are both values that, if not directly available from the
On 24.04.2010, at 05:48, Mark Engelberg wrote:
As far as I know, Clojure doesn't currently make any attempt to
address this problem of allowing a standard way to access public data
from an object, while preserving the option of doing something more
sophisticated later. So a programmer is
You can no
longer take a generic approach to information processing. This results
in an explosion of needless specificity, and a dearth of reuse.
For this reason, I've always found appealing languages which let you
optionally write getter/setter methods that hook into the standard
field
On Sat, 24 Apr 2010 06:51:18 -0700 (PDT)
MarkSwanson mark.swanson...@gmail.com wrote:
You can no
longer take a generic approach to information processing. This results
in an explosion of needless specificity, and a dearth of reuse.
For this reason, I've always found appealing languages
A lot of these arguments go away with functional programming. With a
functional queue, you might as well store the length as a value
attribute because it won't ever change. In some cases I can see the
argument for on-demand computation of fields with referentially
transparent caching. That's where
Neither of those attributes reveal information about the
implementation of the objects in question. They both reveal
information about the state that some client could find useful. They
are both values that, if not directly available from the object should
be calculated by the object, as
On 22 Apr 2010, at 21:15, Konrad Hinsen wrote:
I have several former deftypes that are a perfect fit for the new
defrecord, except that they need a specific comparison function.
This is usually for excluding some fields from equality testing, or
for requiring identity rather than equality
One problem with requiring the other object to be of the same type
is that it would break the current model, e.g.:
user= (= '(1 2 3) [1 2 3])
true
I'm left to wonder if it the more correct implementation of the
desired behavior is not to override the equals, but rather to
implement Comparable.
On Apr 22, 2010, at 3:15 PM, Konrad Hinsen wrote:
On 22.04.2010, at 18:53, Rich Hickey wrote:
Feedback and errata welcome as always,
One feature in the deftype/defrecord split that I regret is that
defrecord no longer allows the redefinition of equals and hashCode.
Any attempt to
On Apr 23, 2010, at 3:12 AM, Konrad Hinsen wrote:
On 22 Apr 2010, at 21:15, Konrad Hinsen wrote:
I have several former deftypes that are a perfect fit for the new
defrecord, except that they need a specific comparison function.
This is usually for excluding some fields from equality
On Apr 22, 2010, at 1:30 PM, Mark Engelberg wrote:
I tried using deftype relatively recently, but realized it wouldn't
work for my needs because serialization via *print-dup* wasn't yet
implemented. I'd recommend including this with the 1.2 release (or is
there a new recommended way to
On Apr 22, 6:53 pm, Rich Hickey richhic...@gmail.com wrote:
[snip..]
Feedback and errata welcome as always,
1) Typo on http://clojure.org/protocols:
Section Basics
defprotocol will automatically generate a corresponding interface,
with the same name as the protocol, i.e. given a protocol
On 23.04.2010, at 17:49, ataggart wrote:
One problem with requiring the other object to be of the same type
is that it would break the current model, e.g.:
user= (= '(1 2 3) [1 2 3])
true
I'd want this only for defrecord, which is a more limited (but also more
convenient) way to define
On 23.04.2010, at 19:20, Rich Hickey wrote:
You can get that back easily by implementing ILookup/IKeywordLookup, as does
defrecord. I still have ideas about macro-like mixins for use in deftype, but
I concluded the mandatory use of such mixins to create record-like things was
too much user
A few meandering observations:
I like the latest change to include a this argument. It makes the
number of arguments line up which is a good thing.
I like the idea of defrecord for the common case, rather than having
to request default implementations of various interfaces within
deftype.
On 24 April 2010 05:48, Mark Engelberg mark.engelb...@gmail.com wrote:
Ideally, I'd like to see a way to allow me to write a program using
(:name employee), and later, if I need to, customize the employee
datatype so that (:name employee) actually dispatches to some other
function. Ditto with
I have been doing some work cleaning up the design and implementation
of datatypes and protocols in preparation for the 1.2 release. Some
notable changes for those who have been working with the earlier
versions:
deftype/reify now take an explicit 'this' argument in method sigs.
The :as option is
I tried using deftype relatively recently, but realized it wouldn't
work for my needs because serialization via *print-dup* wasn't yet
implemented. I'd recommend including this with the 1.2 release (or is
there a new recommended way to serialize Clojure data?)
--
You received this message
On 22.04.2010, at 18:53, Rich Hickey wrote:
Feedback and errata welcome as always,
One feature in the deftype/defrecord split that I regret is that defrecord no
longer allows the redefinition of equals and hashCode. Any attempt to override
those results in an error message about duplicate
On protocols:
- doc string coming after the arg vecs seems odd. I'm used to putting
them after the name of whatever I'm working on.
On protocols doc:
- You can implement a protocol on nil ... Object: could you
elaborate on how these work and/or provide examples? I think this will
solve the one
A good place to look for examples is protocols.clj and gvec.clj in
clojure itself. protocols.clj includes an example of implementing a
protocol on nil.
Stu
On protocols:
- doc string coming after the arg vecs seems odd. I'm used to putting
them after the name of whatever I'm working on.
+1, I am also using this feature of the old deftype.
On Apr 22, 12:15 pm, Konrad Hinsen konrad.hin...@fastmail.net wrote:
On 22.04.2010, at 18:53, Rich Hickey wrote:
Feedback and errata welcome as always,
One feature in the deftype/defrecord split that I regret is that defrecord no
longer
Ah, great! And of course the piece I as missing is that nil and
Object get supported via extend. Makes sense now given that that was
the section of the doc, but it didn't click the first time through.
On Apr 22, 2:54 pm, Stuart Halloway stuart.hallo...@gmail.com wrote:
A good place to look for
Minor errata barely worth mentioning:on the page: http://clojure.org/datatypes
employeee.getName()
employeee needs just 2 'e' characters.
Cheers.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to
On Dec 11, 11:56 pm, ataggart alex.tagg...@gmail.com wrote:
On Dec 11, 11:44 pm, ataggart alex.tagg...@gmail.com wrote:
On Dec 11, 4:14 pm, Jason Wolfe jawo...@berkeley.edu wrote:
I've been trying out the new branch, and on the whole I like it a lot.
I know it'll take some time
On 12 Dec 2009, at 01:14, Jason Wolfe wrote:
A very simple example is: I have a protocol A, and sub-protocols
A1 and A2. Every A is either an A1 or A2, but not both (and this
split is closed, as far as I'm concerned). Sometimes I want to deal
with instances of A1 and A2 together, and so I
On Dec 11, 8:48 am, Chris Kent cjk...@gmail.com wrote:
Rich Hickey richhickey at gmail.com writes:
An updated version of the code for datatypes[1] and protocols[2] is
now available in the 'new' branch[3].
I've converted some code that used gen-class to use deftype and defprotocol
and
Rich Hickey richhickey at gmail.com writes:
An updated version of the code for datatypes[1] and protocols[2] is
now available in the 'new' branch[3].
I've converted some code that used gen-class to use deftype and defprotocol and
the results are great so far. The code is shorter, easier to
I've been trying out the new branch, and on the whole I like it a lot.
I know it'll take some time to learn how do things properly the new
way, and I've figured out how to do most of the things I want to do
thus far. Thanks, Rich!
One thing I haven't figured out how to do cleanly without
On Dec 11, 4:14 pm, Jason Wolfe jawo...@berkeley.edu wrote:
I've been trying out the new branch, and on the whole I like it a lot.
I know it'll take some time to learn how do things properly the new
way, and I've figured out how to do most of the things I want to do
thus far. Thanks, Rich!
On Dec 11, 11:44 pm, ataggart alex.tagg...@gmail.com wrote:
On Dec 11, 4:14 pm, Jason Wolfe jawo...@berkeley.edu wrote:
I've been trying out the new branch, and on the whole I like it a lot.
I know it'll take some time to learn how do things properly the new
way, and I've figured
On Mon, 07 Dec 2009 12:07:12 -0500, Laurent PETIT
laurent.pe...@gmail.com wrote:
2009/12/7 Hugo Duncan hugodun...@users.sourceforge.net
On Mon, 07 Dec 2009 06:53:38 -0500, Rich Hickey richhic...@gmail.com
wrote:
Yes, methods are not really functions. Thinking about them as closures
On 01.12.2009, at 02:42, Rich Hickey wrote:
An updated version of the code for datatypes[1] and protocols[2] is
now available in the 'new' branch[3].
This weekend I finally got around to converting all my deftype-and-
defprotocol-using code to the current Clojure new branch. It is now
more
On Mon, Dec 7, 2009 at 3:11 AM, Konrad Hinsen
konrad.hin...@fastmail.net wrote:
On 01.12.2009, at 02:42, Rich Hickey wrote:
An updated version of the code for datatypes[1] and protocols[2] is
now available in the 'new' branch[3].
This weekend I finally got around to converting all my
On Mon, 07 Dec 2009 06:53:38 -0500, Rich Hickey richhic...@gmail.com
wrote:
Yes, methods are not really functions. Thinking about them as closures
over the object is a good way to go - you can see that analogy in play
when you consider recur, which works with these methods, but could not
2009/12/7 Hugo Duncan hugodun...@users.sourceforge.net
On Mon, 07 Dec 2009 06:53:38 -0500, Rich Hickey richhic...@gmail.com
wrote:
Yes, methods are not really functions. Thinking about them as closures
over the object is a good way to go - you can see that analogy in play
when you
On Dec 7, 9:07 am, Laurent PETIT laurent.pe...@gmail.com wrote:
2009/12/7 Hugo Duncan hugodun...@users.sourceforge.net
On Mon, 07 Dec 2009 06:53:38 -0500, Rich Hickey richhic...@gmail.com
wrote:
Yes, methods are not really functions. Thinking about them as closures
over the object
On Dec 7, 11:23 am, ataggart alex.tagg...@gmail.com wrote:
On Dec 7, 9:07 am, Laurent PETIT laurent.pe...@gmail.com wrote:
2009/12/7 Hugo Duncan hugodun...@users.sourceforge.net
On Mon, 07 Dec 2009 06:53:38 -0500, Rich Hickey richhic...@gmail.com
wrote:
Yes, methods are not
On Dec 1, 9:56 pm, Rich Hickey richhic...@gmail.com wrote:
There are 2 ways to make a deftype reach a protocol. First, you can
implement the protocol directly in the deftype/reify, supplying the
protocol where you do interfaces, and the methods of the protocol as
methods of the type. The type
On Dec 2, 12:29 am, Krukow karl.kru...@gmail.com wrote:
On Dec 1, 10:56 pm, Rich Hickey richhic...@gmail.com wrote:
[snip]
There are 2 ways to make a deftype reach a protocol. First, you can
implement the protocol directly in the deftype/reify, supplying the
protocol where you do
Thanks for sharing the insights.
/Karl
--
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
On Dec 1, 2:42 am, Rich Hickey richhic...@gmail.com wrote:
I have done a lot of work on performance, and refined the design. The
big news is that you can now directly implement a protocol inside a
deftype, and you can also reify protocols. This cements protocols as
the superior way to model
On Dec 1, 10:56 pm, Rich Hickey richhic...@gmail.com wrote:
[snip]
There are 2 ways to make a deftype reach a protocol. First, you can
implement the protocol directly in the deftype/reify, supplying the
protocol where you do interfaces, and the methods of the protocol as
methods of the type.
50 matches
Mail list logo
