Re: how do you name your protocols?

I do this when there is added value, like sone common logic I can wrap on top of the protocol methods that I do not want to call/duplicate in every implementation. But this is quite specific to my own app. The lifecycle's only purpose is to be extended to your own components. Can't see what wo

Re: how do you name your protocols?

I was just refering to the fact that the 'start' protocol method is meant to be called directly by library's users. I'm not using components in any of my projects, so take it with a grain of salt. It seems to me that it would be better (i.e. less coupled, fewer assumptions about the starting proces

Re: how do you name your protocols?

I agree with you and Meikel's points about wrapping protocols with API functions, it makes sense, especially if you want to combine these calls with (Prismatic) schema checks. However, I'm not sure about your point that Stuart made an 'unfortunate' design to 'expose' protocol methods directly,

Re: how do you name your protocols?

I was not implying anything about what Rich have said. While the SPI term may be used in the 'enterprise' field too much (and in an unnecessary complicated manner), I think it has perfectly valid uses in Clojure. The API tells you what a function or a macro does for you, but SPI tells you what

Re: how do you name your protocols?

You're overlooking the fact that a "service provider interface" is simply enterprise design pattern jargon for a subset of public APIs that expose the underlying interfaces of the library to consumers. Saying that Rich is saying protocols should "never ever" be part of the public API is both mi

Re: how do you name your protocols?

I tend to agree. However it is worth noting that there are some libraries in the Clojure ecosystem e.g. Om and stuartsierra/component that do expect users to interact directly with protocols as part of the public API. So this doesn't seem to be yet adopted as a universal rule. On Sunday, 28 De

Re: how do you name your protocols?

Protocols should never ever be part of public API. Protocols can be part of the SPI, if custom extensions are to be supported. Otherwise they are an implementation detail. See Rich's talk at 4:30 http://vimeo.com/100518968 Jozef On Sun, Dec 28, 2014 at 8:11 AM, Mikera wrote: > That depends if t

Re: how do you name your protocols?

That depends if the protocols are part of your user-facing API or not - a lot of the time I find that protocols are best hidden as implementation details rather than exposed to users. In core.matrix, for example, users never see the protocols directly: only implementers of new matrix libraries

Re: how do you name your protocols?

Changing old protocol names should trigger a major revision change in the minimum because it breaks backwards compatibility. --Ashton Sent from my iPhone > On Dec 27, 2014, at 11:18 AM, Michael Klishin > wrote: > >> On 27 December 2014 at 19:10:38, Jozef Wagner (jozef.wag...@gmail.com) wrot

Re: how do you name your protocols?

On 27 December 2014 at 19:10:38, Jozef Wagner (jozef.wag...@gmail.com) wrote: > clj-time seems to be naming protocols inconsistently. It uses > ISomething, Something and SomethingProtocol naming. I suspect it is because it has 60 contributors and most users never have to extend the protocols. F

Re: how do you name your protocols?

clj-time seems to be naming protocols inconsistently. It uses ISomething, Something and SomethingProtocol naming. On Sat, Dec 27, 2014 at 4:20 PM, Matching Socks wrote: > In the interest of thoroughness, it should be noted here that a protocol > *named > "InTimeUnitProtocol" *appears in the Cha

Re: how do you name your protocols?

In the interest of thoroughness, it should be noted here that a protocol *named "InTimeUnitProtocol" *appears in the ChangeLog referenced in the recent announcement of clj-time . -- You received this message because you are subscri

Re: how do you name your protocols?

Clojure API exposes types to the user (Agent, Ref, Var, ...), so it is benefical to see on the first glance whether the name is of a type or interface/protocol. If the API would be built solely on the protocols/interfaces, those prefixes would be of less use. Moreover, I think that names of types

Re: how do you name your protocols?

What might be an advantage to using something like the I-prefix? At first glance, this appears to be unbeneficial hungarian notation. Aesthetically, this seems backwards (to me). I want interfaces and protocols to have the most readable names. I'm willing to concede on less readable names fo

Re: how do you name your protocols?

As you demonstrated, P, I or nothing is up to taste. The only consensus I know of is camel case. https://github.com/bbatsov/clojure-style-guide#CamelCase-for-protocols-records-structs-and-types On Friday, September 5, 2014 2:52:48 AM UTC-7, Dave Sann wrote: > > I saw a comment on protocol naming

Re: how do you name your protocols?

I use IBlah (camel cased, prefixed with capital i) in both Clojure and ClojureScript. It looks better than PBlah and is consistent with how ClojureScript names its protocols. Jozef On Fri, Sep 5, 2014 at 11:52 AM, Dave Sann wrote: > I saw a comment on protocol naming here: > https://groups.goog

how do you name your protocols?

I saw a comment on protocol naming here: https://groups.google.com/d/msg/clojure/A4xIitQWloU/6E4xHDTPPaIJ there is nothing in the coding standards: http://dev.clojure.org/display/community/Library+Coding+Standards (are these maintained?) is there any sensible consensus on good naming conventio