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 would be the added value here, the wrapping fn would only be calling the protocol method. Nothing else... If you require more in your context then define your own wrapper. Nothing generic can help you at this point... I think... Luc P. > 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 process for implementers, more freedom for > Stuart to introduce non-breaking implementation changes) to have a > dedicated start function, that in its simplest form would just call > Lifecycle/start method. > > Jozef > > On Mon, Dec 29, 2014 at 3:40 PM, Malcolm Sparks <malc...@juxt.pro> wrote: > > > 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, it's just a necessary > > consequence of the component design, unless you can suggest an alternative > > approach. > > > > On Sunday, 28 December 2014 16:54:30 UTC, Jozef Wagner wrote: > >> > >> 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 you have to do in order to integrate with existing functionalities. > >> > >> BTW I think protocol methods should be in SPI too. (Stuart's components > >> library made IMO a bit unfortunate decision to expose 'start' and 'stop' > >> protocol methods directly) See http://kotka.de/blog/2011/ > >> 07/Separation_of_concerns.html for a related write-up. > >> > >> Jozef > >> > >> On Sunday, December 28, 2014 4:18:47 PM UTC+1, adrian...@mail.yu.edu > >> wrote: > >>> > >>> 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 misleading and false. > >>> > >>> On Sunday, December 28, 2014 2:50:06 AM UTC-5, Jozef Wagner wrote: > >>>> > >>>> 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 <mike.r.an...@gmail.com> wrote: > >>>> > >>>>> 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 need to care > >>>>> > >>>>> On Sunday, 28 December 2014 02:32:44 UTC+8, Ashton Kemerling wrote: > >>>>>> > >>>>>> 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 < > >>>>>> michael....@gmail.com> wrote: > >>>>>> > > >>>>>> >> On 27 December 2014 at 19:10:38, Jozef Wagner (jozef....@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. > >>>>>> > > >>>>>> > Feel free to submit a PR that standardises all names on Something. > >>>>>> > -- > >>>>>> > @michaelklishin, github.com/michaelklishin > >>>>>> > > >>>>>> > -- > >>>>>> > You received this message because you are subscribed to the Google > >>>>>> > Groups "Clojure" group. > >>>>>> > To post to this group, send email to clo...@googlegroups.com > >>>>>> > Note that posts from new members are moderated - please be patient > >>>>>> with your first post. > >>>>>> > To unsubscribe from this group, send email to > >>>>>> > clojure+u...@googlegroups.com > >>>>>> > For more options, visit this group at > >>>>>> > http://groups.google.com/group/clojure?hl=en > >>>>>> > --- > >>>>>> > You received this message because you are subscribed to the Google > >>>>>> Groups "Clojure" group. > >>>>>> > To unsubscribe from this group and stop receiving emails from it, > >>>>>> send an email to clojure+u...@googlegroups.com. > >>>>>> > For more options, visit https://groups.google.com/d/optout. > >>>>>> > >>>>> > >>>> -- > > 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 unsubscribe from this group, send email to > > clojure+unsubscr...@googlegroups.com > > For more options, visit this group at > > http://groups.google.com/group/clojure?hl=en > > --- > > You received this message because you are subscribed to the Google Groups > > "Clojure" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to clojure+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > > > > -- > 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 unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Luc Prefontaine<lprefonta...@softaddicts.ca> sent by ibisMail! -- 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 unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
