Hello all,
I've been looking at the new protocol (defprotocol, deftype,
defrecord, etc) feature in 1.2 and, while I love the core concepts,
it's been bothering me that there's no apparent way to provide
*automatic* default implementations for methods on a protocol.
I know from reading Rich Hickey
Hi,
2010/8/12 Matthew
> Hello all,
>
> I've been looking at the new protocol (defprotocol, deftype,
> defrecord, etc) feature in 1.2 and, while I love the core concepts,
> it's been bothering me that there's no apparent way to provide
> *automatic* default implementations for methods on a protoc
Does this help?:
http://fulldisclojure.blogspot.com/2010/08/thoughts-on-protocols.html
And Sean's comment here:
http://programming-puzzler.blogspot.com/2010/08/racket-vs-clojure.html
Regards,
Shantanu
On Aug 12, 5:46 pm, Laurent PETIT wrote:
> Hi,
>
> 2010/8/12 Matthew
>
>
>
>
>
>
>
>
>
> >
The other thing that you should consider is that protocols are the contract for
implementers, not the contract for callers. If you change a contract for
implementers, then the implementers *must* change.
Take your example of a function that has a reasonable default for any object.
Often such a
I've been wondering about this topic recently as well.
>Often such a function does not need to be part of the contract for
>implementers (i.e. the protocol) at all.
Stu, (or anybody) I'd like to ask about a variation on this point. How
do you handle the case where you have a general function tha
> Stu, (or anybody) I'd like to ask about a variation on this point. How
> do you handle the case where you have a general function that works
> for every type you'd like to implement a protocol for (thus not
> technically needing to be in a protocol), but maybe 1 or 2 of the many
> types have more
I have been thinking of that too.
The approach of extending with maps is great but lacks of access to
the content of the instance variables of the type.
(def Foo [bar]
)
(extend
clever-automatic-construction
)
As far as I know, clever-automatic-construction cannot use bar in its
implementat
Oh. I forgot.
It could also be helpful to have an easy access (meta information, for
example) to the
fields (and their types) of a record type.
On Thu, Aug 12, 2010 at 7:57 PM, Nicolas Oury wrote:
> I have been thinking of that too.
>
> The approach of extending with maps is great but lacks of a
Good Question, I was wondering that too. Interfaces have some
problems. Protocol solve some of the Problems and Traits solve some
but the do not solve the same. Would be interesting to hear how
Protocols solves those problem, why the don't are problems or why the
don't need to be solved in Clojure
Can I erase my last mails?
I just discovered (.bar (Foo. 5)) => 5
It is a bit embarrassing. Sorry about that. (I am not a Java person, I reckon)
As far as traits are concerned, I think they can be made with a couple
of macros.
I might try to have a go over the week-end.
Best,
Nicolas.
--
You
I've posted a follow up to my article yesterday about protocols & code
reuse. In today's article I discuss what I've termed partially
implemented protocols, which is geared toward providing a default
implementation. Granted, it's a bit ugly and I'll be the first to
admit that it starts to confuse
I find that I'm horribly confused at this point about what a
protocol "is". Can someone use some other comp. sci. terms to
define this idea? I thought of them as Java interfaces with
default methods but clearly I'm wrong.
Sean Devlin wrote:
I've posted a follow up to my article yesterday about p
Protocols are very similar to Java interfaces: they specify a set of
functions/methods without providing an implementation. The big
distinction is in more dynamic usage. Rich Hickey's description at
http://clojure.org/protocols is well written.
On Aug 12, 7:52 pm, Tim Daly wrote:
> I find that I
On Aug 12, 2010, at 7:52 PM, Tim Daly wrote:
I find that I'm horribly confused at this point about what a
protocol "is". Can someone use some other comp. sci. terms to
define this idea? I thought of them as Java interfaces with
default methods but clearly I'm wrong.
Coming from CL, the best
On Fri, Aug 13, 2010 at 1:17 PM, Rich Hickey wrote:
> not. They *sometimes* use interfaces in the implementation, but not always.
> At no point should one assume that because a type supports a protocol it
> 'isA' that protocol (or its interface).
>
That's very interesting. From a performance poin
Hi,
On 13 Aug., 14:58, Nicolas Oury wrote:
> That's very interesting. From a performance point of view, is there a
> penalty involved in being in a case
> where the implementation does not use interfaces?
Using extend is slower, but more dynamic (read: mix-in via map merge
vs. hard-wiring thing
On Fri, Aug 13, 2010 at 2:46 PM, Meikel Brandmeyer wrote:
> Using extend is slower, but more dynamic (read: mix-in via map merge
> vs. hard-wiring things with inline definition).
>
>
Interesting...
Is there a link explaining how it is implemented in the extend
situation and how much slower it is?
@rich
What are your thoughts on the default implementation problem?
On Aug 13, 2:17 pm, Rich Hickey wrote:
> On Aug 12, 2010, at 7:52 PM, Tim Daly wrote:
>
> > I find that I'm horribly confused at this point about what a
> > protocol "is". Can someone use some other comp. sci. terms to
> > define
On Aug 13, 3:38 am, Stuart Halloway wrote:
> > Stu, (or anybody) I'd like to ask about a variation on this
> > point. How do you handle the case where you have a general
> > function that works for every type you'd like to implement a
> > protocol for (thus not technically needing to be in a proto
> Following Stuart's suggestion, I *could* just add a protocol called
> "PrettyPrintable" with one method and implement it on some of the new
> node types, but now I can't just call "pretty-print" on any node: I
> need to write another function that checks if it's a PrettyPrintable
> first and call
> A more concrete example: say I've defined a protocol for AST nodes in
> 1.0 of a library, and later when developing 2.0 I discover it would
> have been a good idea to have a "pretty-print" method on nodes to show
> human-readable output. If the protocol had Trait-like characteristics
> I could ad
so clients don't directly call the protocol functions they call
print-ast which then checks to see if PrettyPrintable has been
extended to the object and falls back to the default if it hasn't
On Thu, Aug 12, 2010 at 6:16 PM, Matthew Phillips wrote:
> On Aug 13, 3:38 am, Stuart Halloway wrote:
>
On Aug 14, 12:34 am, Stuart Halloway
wrote:
> > Following Stuart's suggestion, I *could* just add a protocol
> > called "PrettyPrintable" with one method and implement it on some
> > of the new node types, but now I can't just call "pretty-print" on
> > any node: I need to write another function t
On Aug 14, 9:07 am, Kevin Downey wrote:
> so clients don't directly call the protocol functions they call
> print-ast which then checks to see if PrettyPrintable has been
> extended to the object and falls back to the default if it hasn't
Sure, but I'm talking about publishing protocols that clie
On Aug 14, 3:22 am, Armando Blancas wrote:
> > A more concrete example: say I've defined a protocol for AST nodes in
> > 1.0 of a library, and later when developing 2.0 I discover it would
> > have been a good idea to have a "pretty-print" method on nodes to show
> > human-readable output. If the
> Adding to Object works, but doesn't feel right: as libraries grow,
> they'll start bloating out the method sets on the global Object type.
No, you have this backwards. The protocol is not on Object, Object is on the
protocol. Protocols live in namespaces. You can have 10,000 different protocols
On Sat, Aug 14, 2010 at 5:32 AM, Matthew Phillips wrote:
>
> One idea that I tried was to use extend-type on a protocol, say to
> extend any Node to be a PrettyPrintableNode. Obviously this didn't
> work, and I'm not sure it actually makes semantic sense, but it's
> interesting that was my intuiti
how doesn't it work? the approach of writing your library using
regular functions while protocols provide a simple pluggable lower
bound that users can implement. and when users do implement the simple
protocols they suddenly get all the advanced features of the library
functions, like if you imple
Matthew Phillips writes:
> ;; A node has a data attachment and (possibly) children
> (defprotocol Node
> (data [n])
> (children [n]))
>
> (deftype SimpleNode [d]
> Node
> (data [n] d)
> (children [n] []))
>
> ;; In version 2, I add want to add pretty-printing
>
> (defprotocol PrettyPrin
Thanks to all of you who responded.
So, I think my original thesis was correct: I'm clearly misconstruing
something quite fundamental here ;)
And I can see now my original example was clumsy: for example
something like PrettyPrintable *should* be an orthogonal protocol to
Node. (Not to mention th
Yes, Haskell type classes are the sort of thing I have in mind here I
think. On a type class you can specify default implementations of any
or all of the functions, and they can even refer to themselves
cyclically (e.g the Eq class where == and /= are defined as each
other's complements): the insta
On Mon, Aug 16, 2010 at 3:29 AM, Matthew Phillips wrote:
> ;; Now, if I want any node's in-edges, I can't just call "in-edges"
> ;; because Node implementations won't have it, so I compute them in
> ;; that case.
> (defn node-in-edges [n]
> (if (isa? Node2)
> (in-edges n)
> (compute-node-in
On Aug 12, 10:51 pm, Stuart Halloway
wrote:
> The other thing that you should consider is that protocols are the
> contract for implementers, not the contract for callers. If you
> change a contract for implementers, then the implementers *must*
> change.
>
> Take your example of a function that h
33 matches
Mail list logo
