On May 22, 9:51 pm, Pedro Teixeira wrote:
> On Apr 27, 9:45 am, Rich Hickey 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
On Apr 27, 9:45 am, Rich Hickey 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 latest cha
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 l
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, especially
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
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" construc
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
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 o
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 impl
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 calculati
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
On Sat, 24 Apr 2010 06:51:18 -0700 (PDT)
MarkSwanson 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 which let you
>> 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
On 24 April 2010 05:48, Mark Engelberg 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 (assoc employee :nam
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. Still
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 u
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 de
On Apr 22, 6:53 pm, Rich Hickey 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 my.ns/
Protocol, an in
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 seriali
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 testin
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 overri
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 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 f
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 clojure@googlegro
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 wrote:
> A good place to look for examples is protocols.cl
+1, I am also using this feature of the old deftype.
On Apr 22, 12: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 redefini
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.
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
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 met
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 becaus
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
On Dec 11, 8:48 am, Chris Kent wrote:
> Rich Hickey 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
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, a
On Dec 11, 11:56 pm, ataggart wrote:
> On Dec 11, 11:44 pm, ataggart wrote:
>
>
>
>
>
> > On Dec 11, 4:14 pm, Jason Wolfe 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
On Dec 11, 11:44 pm, ataggart wrote:
> On Dec 11, 4:14 pm, Jason Wolfe 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 thing
On Dec 11, 4:14 pm, Jason Wolfe 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!
>
> One thing
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 inher
Rich Hickey 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 write and
On Mon, 07 Dec 2009 12:07:12 -0500, Laurent PETIT
wrote:
> 2009/12/7 Hugo Duncan
>
>> On Mon, 07 Dec 2009 06:53:38 -0500, Rich Hickey
>> 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
On Dec 1, 9:56 pm, Rich Hickey 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 will be made to
On Dec 7, 11:23 am, ataggart wrote:
> On Dec 7, 9:07 am, Laurent PETIT wrote:
>
>
>
>
>
> > 2009/12/7 Hugo Duncan
>
> > > On Mon, 07 Dec 2009 06:53:38 -0500, Rich Hickey
> > > wrote:
>
> > > > Yes, methods are not really functions. Thinking about them as closures
> > > > over the object is a
On Dec 7, 9:07 am, Laurent PETIT wrote:
> 2009/12/7 Hugo Duncan
>
> > On Mon, 07 Dec 2009 06:53:38 -0500, Rich Hickey
> > 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
> > > whe
2009/12/7 Hugo Duncan
> On Mon, 07 Dec 2009 06:53:38 -0500, Rich Hickey
> 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, bu
On Mon, 07 Dec 2009 06:53:38 -0500, Rich Hickey
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
> rebind 'this'. The
On Mon, Dec 7, 2009 at 3:11 AM, Konrad Hinsen
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 deftype-and-
> defprotocol
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
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 unsubscr
On Dec 2, 12:29 am, Krukow wrote:
> On Dec 1, 10:56 pm, Rich Hickey 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 prot
On Dec 1, 10:56 pm, Rich Hickey 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. The type will be
On Tue, Dec 1, 2009 at 2:59 PM, Krukow wrote:
>
>
> On Dec 1, 2:42 am, Rich Hickey 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 pr
On Dec 1, 2:42 am, Rich Hickey 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 the things for wh
An updated version of the code for datatypes[1] and protocols[2] is
now available in the 'new' branch[3].
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 cement
52 matches
Mail list logo
