The strongest case for using protocols is for working with existing types.
This usually means other people's code, java types etc. This is unique
functionality to clojure and is probably its most important motivation.
This also means that reloading doesn't usually cause issues, since the
types
Hi Sam,
In my experience, protocols are a great mechanism for extensibility. Let's
say you build an abstraction with a default implementation. If your
abstraction is based on protocols, somebody can extend the abstraction to
build a different implementation (that possibly integrates with anothe
As Mark Engelberg writes, if you work in a team, you need to figure this out
with the team.
One point to add to the discussion is that if you find yourself implementing
“several” multi methods per type, it might be worth creating
a protocol, just to make it easier for the consumer to understand
There are two schools of thought:
1. Multimethods are the most versatile and work better at the REPL. Use
protocols only where necessary for performance (and doing so early is
premature optimization).
2. Protocols are the most performant and handle the most common
polymorphism need - single dispat
This article also explains it nicely.
https://8thlight.com/blog/myles-megyesi/2012/04/26/polymorphism-in-clojure.html
--
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
https://www.braveclojure.com/multimethods-records-protocols/
https://stackoverflow.com/questions/8070368/clojure-multimethods-vs-protocols
--
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
N
On Wed, Oct 19, 2016 at 5:00 PM, Paul Gowder wrote:
> Thanks Gregg and Alex! I didn't realize that protocols (or the black
> magic interfacing of core.matrix) were that fancy. Definitely going into
> my "code to really dig into" list.
>
>
It's remotely possible that you might find the following
Thanks Gregg and Alex! I didn't realize that protocols (or the black magic
interfacing of core.matrix) were that fancy. Definitely going into my "code to
really dig into" list.
Cheers,
-Paul
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To pos
On Wednesday, October 19, 2016 at 7:23:21 AM UTC-5, Paul Gowder wrote:
>
> Hi folks,
>
> I have a kinda basic question (I think?) that I should really know the
> answer to after writing Clojure for like 8 months, but don't. It's about
> requiring namespaces with protocol definitions in them b
On Oct 19, 2016 7:23 AM, "Paul Gowder" wrote:
>
> Hi folks,
>
> I have a kinda basic question (I think?) that I should really know the
answer to after writing Clojure for like 8 months, but don't. It's about
requiring namespaces with protocol definitions in them but not the actual
implementations
I read too quickly. I might need multi-methods after all, just like I used
in Common Lisp. I want different types of persisted objects to have the
same interface, if possible.
Actually, I'm just experimenting with protocols, so I'm probably better off
looking for a different use case.
On Mon, Aug
Makes perfect sense. Thanks!
On Mon, Aug 29, 2016 at 5:09 PM Jonathan Fischer
wrote:
> The most straightforward one: just make your protocols a thing that your
> storage medium implements, instead of your records. E.g.:
>
> (defprotocol ThingStore
> (load-item [store item-id])
> (load-items
The most straightforward one: just make your protocols a thing that your
storage medium implements, instead of your records. E.g.:
(defprotocol ThingStore
(load-item [store item-id])
(load-items [store item-ids])
(find-item [store item-name])
(save-item [store item]))
(defrecord Databas
Two options. The first, straightforward one: make the thing that's
implementing the protocol the Storage, not in the individual things being
stored. So something like:
(defprotocol ItemStore
(save-item [store item])
(load-items [store items]))
etc.
Second option: Clojure has multimethods t
Considering the regular use-cases with records:
Create - requires record without any auto-generated identifiers
Retrieve - requires primary identifier or lookup parameters
Update - requires record with primary identifier and updated fields
Delete - requires primary identifier or lookup parameters
Hey Derek,
You're right, I just redefined the Associative implementation to identity,
making it a no-op and then added an IPersistentMap implementation.
It seemed a bit hacky, but in this case performance doesn't matter too
much, so it probably works out OK. It might be that the no-op gets
opti
Hi Neils,
If I've understood you correctly, can you just redefine the protocol
implementation for Associative? E.g.
(defprotocol ProtX
(do-thing [x]))
=> ProtX
(extend clojure.lang.Associative
ProtX
{:do-thing (fn [x] (str/lower-case (get x :a-val)))})
=> nil
(do-thing {:a-val "Some Str
No, it actually compiles down to a pile of ifs, and try/catch/throws (for
backtracking). It's pretty fast, but it won't be as fast as a jump table
for complex matches, that's for sure.
Timothy
On Fri, May 15, 2015 at 5:53 PM, Surgo wrote:
> core.match compiles down to case, does it not? So the
core.match compiles down to case, does it not? So the comparisons here are
similar: http://insideclojure.org/2015/04/27/poly-perf/
-- Morgon
On Friday, May 15, 2015 at 2:57:23 PM UTC-4, tbc++ wrote:
>
> One big thing to consider is that core.match is closed dispatch. If you
> write a function t
One big thing to consider is that core.match is closed dispatch. If you
write a function that uses core.match, I can't extend it inside my code.
This is something that is possible with both multi-methods and protocols.
Timothy
On Fri, May 15, 2015 at 12:49 PM, Sam Raker wrote:
> The discussion/
On Mon, Dec 30, 2013 at 11:30 AM, Cedric Greevey wrote:
> On Mon, Dec 30, 2013 at 12:59 PM, Massimiliano Tomassoli
>> A class must support encapsulation, inheritance and polymorphism. If it
>> doesn't, then it isn't a class. The same way, a method is a function that
>> belongs to a class and can b
On Mon, Dec 30, 2013 at 12:59 PM, Massimiliano Tomassoli wrote:
> On Monday, December 30, 2013 6:31:52 PM UTC+1, Cedric Greevey wrote:
>
>> On Mon, Dec 30, 2013 at 12:30 PM, Massimiliano Tomassoli <
>> kiuh...@gmail.com> wrote:
>>
>>> On Sunday, December 29, 2013 11:30:16 PM UTC+1, Cedric Greevey
On Mon, Dec 30, 2013 at 12:45 PM, Massimiliano Tomassoli wrote:
> On Monday, December 30, 2013 6:27:05 PM UTC+1, Cedric Greevey wrote:
>
>> On Mon, Dec 30, 2013 at 12:13 PM, Massimiliano Tomassoli <
>> kiuh...@gmail.com> wrote:
>>
>>> On Sunday, December 29, 2013 10:11:47 PM UTC+1, tbc++ wrote:
>
There's been a trend against overuse of inheritance, first with java
removing multiple-inheritance and the various private/protected nuanced
inheritances, then generally accepted advice like 'prefer composition over
inheritance'. Some people were still feeling the pain, and some of those
are now u
On Monday, December 30, 2013 6:46:13 PM UTC+1, tbc++ wrote:
>
> And what Cedric says is correct, encapsulation is rarely a good thing, and
> inheritance is overrated.
>
That's your opinion, not a fact.
By saying that something is overrated you're just admitting that many
people don't agree with
Ok, so if we take that definition of classes and methods, then what I'm
saying is that the expression problem can be solved much easier via single
dispatch polymorphic functions, and datatypes. At that point it's just a
question of where the vtable is stored. In C++ it's in the object, in
Clojure,
On Monday, December 30, 2013 6:31:52 PM UTC+1, Cedric Greevey wrote:
>
> On Mon, Dec 30, 2013 at 12:30 PM, Massimiliano Tomassoli <
> kiuh...@gmail.com > wrote:
>
>> On Sunday, December 29, 2013 11:30:16 PM UTC+1, Cedric Greevey wrote:
>>
>>> On Sun, Dec 29, 2013 at 4:11 PM, Timothy Baldridge
>>>
" If the Expression Problem consists in extending classes then non-OOP
languages must be excluded because they don't have classes."
No offense intended, but that is an incredibly wrong statement. Let's look
up the official definition of the expression problem (via wikipedia): "The
goal is to defin
C# extension methods are not polymorphic either. For example, casting a
object to a parent type will cause a different extension method to be run.
This is not the case in normal polymorphism, or for protocols (Clojure is a
dynamic language, so casting doesn't exist anyways).
You're right, you can
On Monday, December 30, 2013 6:27:05 PM UTC+1, Cedric Greevey wrote:
>
> On Mon, Dec 30, 2013 at 12:13 PM, Massimiliano Tomassoli <
> kiuh...@gmail.com > wrote:
>
>> On Sunday, December 29, 2013 10:11:47 PM UTC+1, tbc++ wrote:
>>>
>>> Not mentioned in Cedric's post are two other important things:
>
On Mon, Dec 30, 2013 at 12:30 PM, Massimiliano Tomassoli wrote:
> On Sunday, December 29, 2013 11:30:16 PM UTC+1, Cedric Greevey wrote:
>
>> On Sun, Dec 29, 2013 at 4:11 PM, Timothy Baldridge wrote:
>>
>>> Not mentioned in Cedric's post are two other important things:
>>>
>>> Protocols can be ext
On Sunday, December 29, 2013 11:30:16 PM UTC+1, Cedric Greevey wrote:
>
> On Sun, Dec 29, 2013 at 4:11 PM, Timothy Baldridge
>
> > wrote:
>
>> Not mentioned in Cedric's post are two other important things:
>>
>> Protocols can be extended to existing types.
>>
>
> These are important for the Expre
On Mon, Dec 30, 2013 at 12:13 PM, Massimiliano Tomassoli wrote:
> On Sunday, December 29, 2013 10:11:47 PM UTC+1, tbc++ wrote:
>>
>> Not mentioned in Cedric's post are two other important things:
>>
>> Protocols can be extended to existing types. For example:
>>
>> (defprotocol IType
>> (type-a
On Sunday, December 29, 2013 10:11:47 PM UTC+1, tbc++ wrote:
>
> Not mentioned in Cedric's post are two other important things:
>
> Protocols can be extended to existing types. For example:
>
> (defprotocol IType
> (type-as-string [x]))
>
> (extend-protocol IType
> String
> (type-as-string [x
Yeah, it was sometime in the 90s. The only workaround I could think of was
maybe to create a single compilation unit for template use, and there
derive a trivial subclass of each used template specialization, then use
that subclass elsewhere in lieu of the template. Needless to say, not a
solution
That must have been a long time ago? That problem was solved well
before I left the C++ committee in '99 and gcc was normally pretty
good at tracking the emerging standard at the time...
But, yes, the template compilation model and it's impact on linking
modules that specialized the same template
On Sun, Dec 29, 2013 at 4:11 PM, Timothy Baldridge wrote:
> Not mentioned in Cedric's post are two other important things:
>
> Protocols can be extended to existing types.
>
These are important for the Expression Problem, but not for the OP's query
as originally stated, which simply asked for the
The expression problem is about what kinds of additions and extensions you
can easily make *without modifying or recompiling the existing codebase.*
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googl
Not mentioned in Cedric's post are two other important things:
Protocols can be extended to existing types. For example:
(defprotocol IType
(type-as-string [x]))
(extend-protocol IType
String
(type-as-string [x] "string")
Integer
(type-as-string [x] "integer"))
=> (type-as-string 42)
On Sunday, December 29, 2013 7:05:28 PM UTC+1, Cedric Greevey wrote:
>
> On Sun, Dec 29, 2013 at 12:27 PM, Massimiliano Tomassoli <
> kiuh...@gmail.com > wrote:
>
>> What's the difference between protocols and simple overloading?
>>
>
> Dynamic dispatch. Overloading uses just the static type for di
On Sun, Dec 29, 2013 at 12:27 PM, Massimiliano Tomassoli wrote:
> What's the difference between protocols and simple overloading?
>
Dynamic dispatch. Overloading uses just the static type for dispatch, so
this Java code:
aBase = new Base();
aDerived = new Derived();
aBase2 = aDerived;
something
> There's also defrecord
I considered using that, but I need to do something more with the
constructor (e.g. convert the map into a Java array for internal
use). Also, defrecords only takes positional arguments, which will be
hard to use with tens of arguments. (An alternative is just to pass
in
On Fri, Feb 10, 2012 at 1:07 PM, Aaron Cohen wrote:
> On Fri, Feb 10, 2012 at 3:13 AM, drewn wrote:
>> I've just started learning protocols, deftype, etc. The first thing I
>> did was try to extend a Clojure type (maps) to operate as a
>> specialized Java Swing interface (AttributeSet), forgetti
On Fri, Feb 10, 2012 at 3:13 AM, drewn wrote:
> I've just started learning protocols, deftype, etc. The first thing I
> did was try to extend a Clojure type (maps) to operate as a
> specialized Java Swing interface (AttributeSet), forgetting that
> interfaces are not protocols; i.e.
>
> (extend-t
> Nope, can't be done. Java interfaces can't do this.
I'm glad I asked the question. Given that it can't be done, any
suggestions for the best way of handling this interop scenario?
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this gro
Nope, can't be done. Java interfaces can't do this.
Java 8 may have "Interface Injection" which will make this possible.
-S
--
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
On Tue, Aug 30, 2011 at 7:29 PM, Ambrose Bonnaire-Sergeant
wrote:
> I've seen a common pattern of putting functions you want used by other
> namespaces in a group at
> the bottom of the file. The lack of forward declarations also encourages
> this.
Yep, I've already done that, just reasoning abo
Hi Sergio,
I think the public/private function options cover your bases here.
If you have so many public functions in a namespace, possibly could be a
sign to separate
them into other namespaces, possibly nested.
I certainly think using protocols for this would be an abuse.
I've seen a common p
On Jul 28, 2011, at 8:19 PM, Alex Osborne wrote:
> The main use cases for the old structs feature on the other hand are
> completely replaced by records and it is recommended that new code use
> defrecord instead of defstruct.
I had some code using structs and, following advice like this, replace
Thank you everyone. I now have a much better understanding of
protocols aed records. This video helped too http://vimeo.com/11236603
On Jul 29, 3:01 pm, Jeff Heon wrote:
> Thanks for the clarification. I see I was mixing up various concepts
> in my head.
>
> On Jul 29, 8:19 am, Alex Osborne wrot
Thanks for the clarification. I see I was mixing up various concepts
in my head.
On Jul 29, 8:19 am, Alex Osborne wrote:
> Clojure has some of those features, but it is sufficiently different
> from the traditional model that I would consider "not particularly OO" a
> valid, if not particularly u
Jeff Heon writes:
> I'm puzzled when we say that Clojure is not particularly OO, but using
> protocols and datatypes feel OO to me,
> except that the namespace of the protocol method implementations is
> decoupled from the namespace of the type.
>
> Perhaps my definition of OO is too loose and I
> I'm puzzled when we say that Clojure is not particularly OO, but using
> protocols and datatypes feel OO to me,
> except that the namespace of the protocol method implementations is
> decoupled from the namespace of the type.
>
> Perhaps my definition of OO is too loose and I should think of
> pr
I'm puzzled when we say that Clojure is not particularly OO, but using
protocols and datatypes feel OO to me,
except that the namespace of the protocol method implementations is
decoupled from the namespace of the type.
Perhaps my definition of OO is too loose and I should think of
protocols as "j
Oskar writes:
> Why protocols (and records)? What benefits do I get? Alex mentioned
> polymorphism; how is this different from/related to multimethods?
As Andreas mentioned, yes protocols basically give you a subset of the
polymorphism functionality of multimethods. But they also give you some
I would say that protocols are a subset of multimethod functionality.
You want protocols because they are faster and simpler.
Protocols only does dispatch on the type, with multimethods you can do
dispatch on several args of whatever.
2011/7/28 Oskar
> Thank you Alex and abp!
>
> Your posts ce
Thank you Alex and abp!
Your posts certainly contains valuable information. But I have
questions still. One might say that you explained how to use
protocols, but the questions I have left are: Why protocols (and
records)? What benefits do I get? Alex mentioned polymorphism; how is
this different
Many thanks, abp and Alex.
Additionally I think this post (and original discussion here) is also
worth reading:
http://kotka.de/blog/2011/07/Separation_of_concerns.html
though the conclusion is not the community consensus (for now).
--
Name: OGINO Masanori (荻野 雅紀)
E-mail: masanori.og...@gmail.c
Thanks Alex! It's much clearer now to me as well.
--
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.
T
(nothing to add, just wanted to say that explanation has certainly clarified
things for me. These excellent replies, as oppose to "go read XYZ" really
differentiate this community! Thanks again)
On 28 July 2011 12:46, Alex Osborne wrote:
> Oskar writes:
>
> > I have not heard much about recor
Oskar writes:
> I have not heard much about records and protocols. What is a typical
> use case in idiomatic Clojure code for them? Is it a good idea, for
> example, to make a "Character" protocol and "Player" and "Monster"
> records or something in a game. It feels a bit too much like OOP for
>
Have a look at this:
http://cemerick.com/2011/07/05/flowchart-for-choosing-the-right-clojure-type-definition-form/
Now, as far as i understood, you define a protocol and the extend it
on types defined via defrecord.
That's more like Character is a protocol that defines functions for
movement, at
It has worked like a charm.
Thanks.
Juan Manuel
On 11 abr, 16:45, Meikel Brandmeyer wrote:
> Hi,
>
> On 11 Apr., 16:35, babui wrote:
>
> > (ns b
> > (:use a :as mya))
>
> You want require here, not use. (ns b (:require [a :as mya]))
>
> Sincerely
> Meikel
--
You received this message bec
Hi,
On 11 Apr., 16:35, babui wrote:
> (ns b
> (:use a :as mya))
You want require here, not use. (ns b (:require [a :as mya]))
Sincerely
Meikel
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@google
I'm having trouble avoiding name collisions with protocols. A third-
party librery defines:
(ns a)
(defprotocol PA
(fa [this ...])
(ga [this ..])
(ha [this ..])
.)
And i want to be able to use some of this protocol for a type I'm
defining. So I do
(ns b
(:use a :as mya))
(d
Do protocols respect namespace rewriting? For instance:
We define a protocol in a namespace:
(ns a)
(defprotocol P
(p [this]))
(defn g[] )
This works:
(ns b
On 6 abr, 00:02, Stuart Sierra wrote:
> You can omit clojure.core/first from your namespace like this:
>
> (ns your.namespace
You can omit clojure.core/first from your namespace like this:
(ns your.namespace
(:refer-clojure :exclude (first)))
Users of your library could do the same, and also `(:use your.namespace)` to
have access to your alternate definition of `first`.
-Stuart Sierra
clojure.com
--
You received t
You can't turn clojure.core/first into a protocol - it's already a
bare function. When you define a protocol with a first method, you
define a new function in your namespace called first, which delegates
to protocol implementations. The compiler is complaining that you're
shadowing clojure.core/fir
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
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
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
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
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
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
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
> 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 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
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, 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
IPersistentMap is an interface, which are sort of the java analog of
protocols, and in fact last I checked protocols generate named java
interfaces, so I think you're fine
On Fri, Aug 13, 2010 at 5:10 PM, Brenton wrote:
> Greetings,
>
> Suppose that I create a function that is designed to receive
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:
>
> 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
> 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
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
@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 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?
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 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
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
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
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
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
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
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
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
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
> 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'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
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
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
>
>
>
>
>
>
>
>
>
> >
1 - 100 of 122 matches
Mail list logo
