Ask Community: Feedback/Suggestion Needed about the Code Nirvana Specification

2018-11-08 Thread Piyush Katariya
Hello Clojurians,

 Could you please have a look at the specification of Code Nirvana and 
share your feedback/opinion/suggestion about it in terms of its need, 
usability and productivity
 
https://docs.google.com/document/d/e/2PACX-1vTK7FVU-tPUwM8FXP33-qqPZk3pUOm4JI0JbOxHwkKmMH0skIxviOsEwB4ek_x_d9L8teI4dGWT-Avs/pub


Thanks,
Piyush Katariya

-- 
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.


RE: An Error spec?

2018-11-08 Thread Sean Corfield
Alex, I’m curious, should this 
https://github.com/dawcs/flow/blob/master/src/dawcs/flow.clj#L53 use 
*exception-base-class* rather than Throwable directly?

It looks very interesting and elegant – I’ll probably give this a test drive 
next week!

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood


From: clojure@googlegroups.com  on behalf of alex 

Sent: Wednesday, November 7, 2018 2:05:28 PM
To: Clojure
Subject: Re: An Error spec?

How about using exception instances as errors? That plays pretty nicely with 
ex-info and (try ... (catch Exception e e)). I've built 
https://github.com/dawcs/flow on top of that approach  and that seems like 
pretty good abstraction. Despite I'm not sure about CLJS.
Anomalies are also great and you may check out 
https://github.com/dawcs/anomalies-tools for some tooling around it. But you 
may still need a bridge to convert exceptions caught from 3rd-party java libs 
into anomalies structure. And despite Cognitect roots, it doesn't feel like 
"official standard".

пятница, 26 октября 2018 г., 4:46:54 UTC+3 пользователь Didier написал:
I've started to see a pattern in my spec like this:

(s/or :success string?
  :error ::error)

And I've been tempted to create my own spec macro for this. But I also thought, 
maybe Spec itself should have such a spec.

(s/error  )

What do people think?

--
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.


Re: An Error spec?

2018-11-08 Thread alex
Thanks Sean, simple api is really main goal in Flow design. Initially we 
had much more sugar, but resulting version is pretty concise. We use it in 
production at Eventum, mostly in graphql resolvers/mutations and we're 
quite happy with it. 

четверг, 8 ноября 2018 г., 21:18:18 UTC+2 пользователь Sean Corfield 
написал:
>
> Flow reminds me a bit of a project I started in early 2015 and decided to 
> sunset in late 2016: https://github.com/seancorfield/engine
>
>  
>
> We actually used Engine at work for a while but decided the resulting code 
> was both harder to read and not really very idiomatic. I’ll be interested 
> to hear how people find Flow in production – it’s a lot more focused and 
> simpler than Engine (which is definitely a good thing!  ).
>
>  
>
> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
>
>  
> --
> *From:* clo...@googlegroups.com   > on behalf of alex >
> *Sent:* Wednesday, November 7, 2018 2:05:28 PM
> *To:* Clojure
> *Subject:* Re: An Error spec? 
>  
> How about using exception instances as errors? That plays pretty nicely 
> with ex-info and (try ... (catch Exception e e)). I've built 
> https://github.com/dawcs/flow on top of that approach  and that seems 
> like pretty good abstraction. Despite I'm not sure about CLJS. 
> Anomalies are also great and you may check out 
> https://github.com/dawcs/anomalies-tools for some tooling around it. But 
> you may still need a bridge to convert exceptions caught from 3rd-party 
> java libs into anomalies structure. And despite Cognitect roots, it doesn't 
> feel like "official standard".  
>
> пятница, 26 октября 2018 г., 4:46:54 UTC+3 пользователь Didier написал: 
>>
>> I've started to see a pattern in my spec like this:
>>
>> (s/or :success string?
>>   :error ::error)
>>
>> And I've been tempted to create my own spec macro for this. But I also 
>> thought, maybe Spec itself should have such a spec.
>>
>> (s/error  )
>>
>> What do people think?
>>
> -- 
> 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.


RE: An Error spec?

2018-11-08 Thread Sean Corfield
Flow reminds me a bit of a project I started in early 2015 and decided to 
sunset in late 2016: https://github.com/seancorfield/engine

We actually used Engine at work for a while but decided the resulting code was 
both harder to read and not really very idiomatic. I’ll be interested to hear 
how people find Flow in production – it’s a lot more focused and simpler than 
Engine (which is definitely a good thing!  ).

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood


From: clojure@googlegroups.com  on behalf of alex 

Sent: Wednesday, November 7, 2018 2:05:28 PM
To: Clojure
Subject: Re: An Error spec?

How about using exception instances as errors? That plays pretty nicely with 
ex-info and (try ... (catch Exception e e)). I've built 
https://github.com/dawcs/flow on top of that approach  and that seems like 
pretty good abstraction. Despite I'm not sure about CLJS.
Anomalies are also great and you may check out 
https://github.com/dawcs/anomalies-tools for some tooling around it. But you 
may still need a bridge to convert exceptions caught from 3rd-party java libs 
into anomalies structure. And despite Cognitect roots, it doesn't feel like 
"official standard".

пятница, 26 октября 2018 г., 4:46:54 UTC+3 пользователь Didier написал:
I've started to see a pattern in my spec like this:

(s/or :success string?
  :error ::error)

And I've been tempted to create my own spec macro for this. But I also thought, 
maybe Spec itself should have such a spec.

(s/error  )

What do people think?

--
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.


Re: [ANN] 1.10.0-beta5

2018-11-08 Thread Timothy Baldridge
Nope, you're right, I missed the "extend, extend-type, extend-protocol"
part of the original post.

On Thu, Nov 8, 2018 at 10:12 AM Alex Miller  wrote:

>
> On Thursday, November 8, 2018 at 10:44:34 AM UTC-6, tbc++ wrote:
>>
>> The instance based polymorphism is a bit wonky in some cases. Can we get
>> some sort of spec that tells us what the rules are for resolution?
>>
>
> From the top of the thread: "Protocol implementations are checked first
> for direct definitions (defrecord, deftype, reify), then metadata
> definitions, then external extensions (extend, extend-type,
> extend-protocol)."  Was that unclear in some way? I think it explains
> everything you're seeing.
>
> We do plan to update the protocols reference page for final release, but
> waiting on that.
>
> We are still doing performance eval on this too - still might change a bit
> more.
>
>
>
>
>> See these cases where it breaks in some rather strange ways.
>>
>> Clojure 1.10.0-beta5
>> user=> (defprotocol ILevel (level [this]))
>> ILevel
>> user=> (extend-protocol ILevel
>>  clojure.lang.IPersistentVector
>>  (level [this] "interface"))
>> nil
>> user=> (extend-protocol ILevel
>>  Object
>>  (level [this] "object"))
>> nil
>> user=> (level [])
>> "interface"
>> user=> (level :key)
>> "object"
>> user=> (level (with-meta 'foo {`level (fn [this] "instance")}))
>> "instance"
>> user=> (level (with-meta [] {`level (fn [this] "instance")}))
>> "instance"
>> user=> (defrecord MyType [] ILevel (level [this] "type"))
>> user.MyType
>> ;; Fails to override
>> user=> (level (with-meta (->MyType) {`level (fn [this] "instance")}))
>> "type"
>> user=> (defrecord MyType3 [])
>> user.MyType3
>> user=> (extend-protocol ILevel
>>  MyType3
>>  (level [this] "type"))
>> nil
>> user=> (level (->MyType3))
>> "type"
>> ;; Overrides
>> user=> (level (with-meta (->MyType3) {`level (fn [this] "instance")}))
>> "instance"
>> user=>
>>
>> So it looks like if someone uses inline protocol extension that class
>> cannot participate in instance level polymorphism. If however they use
>> extend on the type after it's defined then the behavior changes and
>> instance polymorphism is supported.
>>
>>
>> --
> 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.
>


-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

-- 
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.


Re: [ANN] 1.10.0-beta5

2018-11-08 Thread Alex Miller

On Thursday, November 8, 2018 at 10:44:34 AM UTC-6, tbc++ wrote:
>
> The instance based polymorphism is a bit wonky in some cases. Can we get 
> some sort of spec that tells us what the rules are for resolution? 
>

>From the top of the thread: "Protocol implementations are checked first for 
direct definitions (defrecord, deftype, reify), then metadata definitions, 
then external extensions (extend, extend-type, extend-protocol)."  Was that 
unclear in some way? I think it explains everything you're seeing.

We do plan to update the protocols reference page for final release, but 
waiting on that. 

We are still doing performance eval on this too - still might change a bit 
more. 


 

> See these cases where it breaks in some rather strange ways.
>
> Clojure 1.10.0-beta5
> user=> (defprotocol ILevel (level [this]))
> ILevel
> user=> (extend-protocol ILevel
>  clojure.lang.IPersistentVector
>  (level [this] "interface"))
> nil
> user=> (extend-protocol ILevel
>  Object
>  (level [this] "object"))
> nil
> user=> (level [])
> "interface"
> user=> (level :key)
> "object"
> user=> (level (with-meta 'foo {`level (fn [this] "instance")}))
> "instance"
> user=> (level (with-meta [] {`level (fn [this] "instance")}))
> "instance"
> user=> (defrecord MyType [] ILevel (level [this] "type"))
> user.MyType
> ;; Fails to override
> user=> (level (with-meta (->MyType) {`level (fn [this] "instance")}))
> "type"
> user=> (defrecord MyType3 [])
> user.MyType3
> user=> (extend-protocol ILevel
>  MyType3
>  (level [this] "type"))
> nil
> user=> (level (->MyType3))
> "type"
> ;; Overrides
> user=> (level (with-meta (->MyType3) {`level (fn [this] "instance")}))
> "instance"
> user=>
>
> So it looks like if someone uses inline protocol extension that class 
> cannot participate in instance level polymorphism. If however they use 
> extend on the type after it's defined then the behavior changes and 
> instance polymorphism is supported.
>  
>
>

-- 
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.


Re: [ANN] 1.10.0-beta5

2018-11-08 Thread Timothy Baldridge
The instance based polymorphism is a bit wonky in some cases. Can we get
some sort of spec that tells us what the rules are for resolution? See
these cases where it breaks in some rather strange ways.

Clojure 1.10.0-beta5
user=> (defprotocol ILevel (level [this]))
ILevel
user=> (extend-protocol ILevel
 clojure.lang.IPersistentVector
 (level [this] "interface"))
nil
user=> (extend-protocol ILevel
 Object
 (level [this] "object"))
nil
user=> (level [])
"interface"
user=> (level :key)
"object"
user=> (level (with-meta 'foo {`level (fn [this] "instance")}))
"instance"
user=> (level (with-meta [] {`level (fn [this] "instance")}))
"instance"
user=> (defrecord MyType [] ILevel (level [this] "type"))
user.MyType
;; Fails to override
user=> (level (with-meta (->MyType) {`level (fn [this] "instance")}))
"type"
user=> (defrecord MyType3 [])
user.MyType3
user=> (extend-protocol ILevel
 MyType3
 (level [this] "type"))
nil
user=> (level (->MyType3))
"type"
;; Overrides
user=> (level (with-meta (->MyType3) {`level (fn [this] "instance")}))
"instance"
user=>

So it looks like if someone uses inline protocol extension that class
cannot participate in instance level polymorphism. If however they use
extend on the type after it's defined then the behavior changes and
instance polymorphism is supported.


On Thu, Nov 8, 2018 at 9:24 AM Rick Moynihan 
wrote:

> On Thu, 8 Nov 2018 at 14:36, alex  wrote:
>
>> No, that will not work exactly like Ruby eigenclass, cause eigenclass has
>> a priority when method lookup is performed. In Clojure case if instance's
>> class has implementation of method, it will be preferred instead of meta
>> version. If I understand everything correctly.
>>
>
> Yes, clearly it'll not be exactly like Ruby eigenclasses; because this is
> clojure! :-)  My point was really that it's spiritually similar if you
> consider them as a means of extending individual instances you're given
> with new functionality.  Though yes, thankfully you can't use this for
> monkey patching over existing functionality; but who would want to do
> that?! ;-)
>
> R.
>
>
>>
>> четверг, 8 ноября 2018 г., 12:33:10 UTC+2 пользователь Rick Moynihan
>> написал:
>>>
>>> Cool, so I guess it's the clojure of equivalent of Ruby's eigenclasses:
>>>
>>> f = "some object"
>>> class << f
>>>   def foo
>>>  "new foo method on f"
>>>   end
>>> end
>>>
>>> f.foo # => "new foo method on f"
>>>
>>> It's a shame this mechanism only works for values implementing IMeta,
>>> but I understand the JVM is a little prohibitive in this regard.
>>>
>>> Even so I suppose the main use of this is that it lets a caller give you
>>> a value, and you can return a plussed up version with new capabilities,
>>> without having to return a wrapped value.  Wrapped values are sometimes
>>> problematic because they introduce new representations of existing types,
>>> and this allows an API to return values to the caller that behave the same
>>> as what went in.  Neat!
>>>
>>> R.
>>>
>>> On Tue, 6 Nov 2018 at 15:51, Alex Miller  wrote:
>>>

 On Tuesday, November 6, 2018 at 9:25:31 AM UTC-6, John Schmidt wrote:
>
> Nice to see continued progress on Clojure 1.10!
>
> It is not clear to me what metadata extension provides that is not
> already possible with direct definitions or external extensions. Some
> additional background or a small motivating example would be much
> appreciated in clearing up the confusion!
>

 Metadata extension allows you to implement protocols on a per-value
 basis (the others are type/class-oriented). This opens up a whole new range
 of potential uses for protocols. Rich was already using this approach for
 the new datafy/nav functionality - this made it generic for all protocols.

 Any collection instance can carry metadata, so you can take any
 collection instance and dynamically extend a protocol to it by adding
 metadata. So if you think about something like Component, which has a
 Lifecycle protocol for start/stop, you can now make lightweight components
 without needing to make a type or reify:

 $ clj -Sdeps '{:deps {org.clojure/clojure {:mvn/version
 "1.10.0-beta5"}, com.stuartsierra/component {:mvn/version "0.3.2"}}}'
 Clojure 1.10.0-beta5
 user=> (require '[com.stuartsierra.component :as component])
 nil
 user=> (def c (with-meta {:state :init}
 {`component/start (fn [c] (assoc c :state :started))
  `component/stop (fn [c] (assoc c :state :stopped))}))
 #'user/c
 user=> (component/start c)
 {:state :started}
 user=> (component/stop c)
 {:state :stopped}


 --
 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
 

Re: [ANN] 1.10.0-beta5

2018-11-08 Thread Rick Moynihan
On Thu, 8 Nov 2018 at 14:36, alex  wrote:

> No, that will not work exactly like Ruby eigenclass, cause eigenclass has
> a priority when method lookup is performed. In Clojure case if instance's
> class has implementation of method, it will be preferred instead of meta
> version. If I understand everything correctly.
>

Yes, clearly it'll not be exactly like Ruby eigenclasses; because this is
clojure! :-)  My point was really that it's spiritually similar if you
consider them as a means of extending individual instances you're given
with new functionality.  Though yes, thankfully you can't use this for
monkey patching over existing functionality; but who would want to do
that?! ;-)

R.


>
> четверг, 8 ноября 2018 г., 12:33:10 UTC+2 пользователь Rick Moynihan
> написал:
>>
>> Cool, so I guess it's the clojure of equivalent of Ruby's eigenclasses:
>>
>> f = "some object"
>> class << f
>>   def foo
>>  "new foo method on f"
>>   end
>> end
>>
>> f.foo # => "new foo method on f"
>>
>> It's a shame this mechanism only works for values implementing IMeta, but
>> I understand the JVM is a little prohibitive in this regard.
>>
>> Even so I suppose the main use of this is that it lets a caller give you
>> a value, and you can return a plussed up version with new capabilities,
>> without having to return a wrapped value.  Wrapped values are sometimes
>> problematic because they introduce new representations of existing types,
>> and this allows an API to return values to the caller that behave the same
>> as what went in.  Neat!
>>
>> R.
>>
>> On Tue, 6 Nov 2018 at 15:51, Alex Miller  wrote:
>>
>>>
>>> On Tuesday, November 6, 2018 at 9:25:31 AM UTC-6, John Schmidt wrote:

 Nice to see continued progress on Clojure 1.10!

 It is not clear to me what metadata extension provides that is not
 already possible with direct definitions or external extensions. Some
 additional background or a small motivating example would be much
 appreciated in clearing up the confusion!

>>>
>>> Metadata extension allows you to implement protocols on a per-value
>>> basis (the others are type/class-oriented). This opens up a whole new range
>>> of potential uses for protocols. Rich was already using this approach for
>>> the new datafy/nav functionality - this made it generic for all protocols.
>>>
>>> Any collection instance can carry metadata, so you can take any
>>> collection instance and dynamically extend a protocol to it by adding
>>> metadata. So if you think about something like Component, which has a
>>> Lifecycle protocol for start/stop, you can now make lightweight components
>>> without needing to make a type or reify:
>>>
>>> $ clj -Sdeps '{:deps {org.clojure/clojure {:mvn/version
>>> "1.10.0-beta5"}, com.stuartsierra/component {:mvn/version "0.3.2"}}}'
>>> Clojure 1.10.0-beta5
>>> user=> (require '[com.stuartsierra.component :as component])
>>> nil
>>> user=> (def c (with-meta {:state :init}
>>> {`component/start (fn [c] (assoc c :state :started))
>>>  `component/stop (fn [c] (assoc c :state :stopped))}))
>>> #'user/c
>>> user=> (component/start c)
>>> {:state :started}
>>> user=> (component/stop c)
>>> {:state :stopped}
>>>
>>>
>>> --
>>> 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

Re: [ANN] 1.10.0-beta5

2018-11-08 Thread alex
No, that will not work exactly like Ruby eigenclass, cause eigenclass has a 
priority when method lookup is performed. In Clojure case if instance's 
class has implementation of method, it will be preferred instead of meta 
version. If I understand everything correctly.

четверг, 8 ноября 2018 г., 12:33:10 UTC+2 пользователь Rick Moynihan 
написал:
>
> Cool, so I guess it's the clojure of equivalent of Ruby's eigenclasses:
>
> f = "some object"
> class << f
>   def foo 
>  "new foo method on f"
>   end
> end
>
> f.foo # => "new foo method on f"
>
> It's a shame this mechanism only works for values implementing IMeta, but 
> I understand the JVM is a little prohibitive in this regard.
>
> Even so I suppose the main use of this is that it lets a caller give you a 
> value, and you can return a plussed up version with new capabilities, 
> without having to return a wrapped value.  Wrapped values are sometimes 
> problematic because they introduce new representations of existing types, 
> and this allows an API to return values to the caller that behave the same 
> as what went in.  Neat!
>
> R.
>
> On Tue, 6 Nov 2018 at 15:51, Alex Miller  > wrote:
>
>>
>> On Tuesday, November 6, 2018 at 9:25:31 AM UTC-6, John Schmidt wrote:
>>>
>>> Nice to see continued progress on Clojure 1.10!
>>>
>>> It is not clear to me what metadata extension provides that is not 
>>> already possible with direct definitions or external extensions. Some 
>>> additional background or a small motivating example would be much 
>>> appreciated in clearing up the confusion!
>>>
>>
>> Metadata extension allows you to implement protocols on a per-value basis 
>> (the others are type/class-oriented). This opens up a whole new range of 
>> potential uses for protocols. Rich was already using this approach for the 
>> new datafy/nav functionality - this made it generic for all protocols.
>>
>> Any collection instance can carry metadata, so you can take any 
>> collection instance and dynamically extend a protocol to it by adding 
>> metadata. So if you think about something like Component, which has a 
>> Lifecycle protocol for start/stop, you can now make lightweight components 
>> without needing to make a type or reify:
>>
>> $ clj -Sdeps '{:deps {org.clojure/clojure {:mvn/version "1.10.0-beta5"}, 
>> com.stuartsierra/component {:mvn/version "0.3.2"}}}'
>> Clojure 1.10.0-beta5
>> user=> (require '[com.stuartsierra.component :as component])
>> nil
>> user=> (def c (with-meta {:state :init} 
>> {`component/start (fn [c] (assoc c :state :started))
>>  `component/stop (fn [c] (assoc c :state :stopped))}))
>> #'user/c
>> user=> (component/start c)
>> {:state :started}
>> user=> (component/stop c)
>> {:state :stopped}
>>
>>
>> -- 
>> 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.


Re: [ANN] 1.10.0-beta5

2018-11-08 Thread Rick Moynihan
Cool, so I guess it's the clojure of equivalent of Ruby's eigenclasses:

f = "some object"
class << f
  def foo
 "new foo method on f"
  end
end

f.foo # => "new foo method on f"

It's a shame this mechanism only works for values implementing IMeta, but I
understand the JVM is a little prohibitive in this regard.

Even so I suppose the main use of this is that it lets a caller give you a
value, and you can return a plussed up version with new capabilities,
without having to return a wrapped value.  Wrapped values are sometimes
problematic because they introduce new representations of existing types,
and this allows an API to return values to the caller that behave the same
as what went in.  Neat!

R.

On Tue, 6 Nov 2018 at 15:51, Alex Miller  wrote:

>
> On Tuesday, November 6, 2018 at 9:25:31 AM UTC-6, John Schmidt wrote:
>>
>> Nice to see continued progress on Clojure 1.10!
>>
>> It is not clear to me what metadata extension provides that is not
>> already possible with direct definitions or external extensions. Some
>> additional background or a small motivating example would be much
>> appreciated in clearing up the confusion!
>>
>
> Metadata extension allows you to implement protocols on a per-value basis
> (the others are type/class-oriented). This opens up a whole new range of
> potential uses for protocols. Rich was already using this approach for the
> new datafy/nav functionality - this made it generic for all protocols.
>
> Any collection instance can carry metadata, so you can take any collection
> instance and dynamically extend a protocol to it by adding metadata. So if
> you think about something like Component, which has a Lifecycle protocol
> for start/stop, you can now make lightweight components without needing to
> make a type or reify:
>
> $ clj -Sdeps '{:deps {org.clojure/clojure {:mvn/version "1.10.0-beta5"},
> com.stuartsierra/component {:mvn/version "0.3.2"}}}'
> Clojure 1.10.0-beta5
> user=> (require '[com.stuartsierra.component :as component])
> nil
> user=> (def c (with-meta {:state :init}
> {`component/start (fn [c] (assoc c :state :started))
>  `component/stop (fn [c] (assoc c :state :stopped))}))
> #'user/c
> user=> (component/start c)
> {:state :started}
> user=> (component/stop c)
> {:state :stopped}
>
>
> --
> 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.