Re: Interop: mutability vs. inheritance

2015-05-28 Thread Mars0i


 I think that's correct (with the exception you already mention yourself: 
 you can use a :state structure containing multiple values). 

 OK. 

If you care mostly about performance, maybe using an array as :state 
 will do.  That's always mutable and access is really fast. 


Oh, nice idea.  I forgot about that option. 

Thanks.

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


Interop: mutability vs. inheritance

2015-05-27 Thread Mars0i
Is the following correct?

The only way to define *multiple* mutable instance variables/fields for a 
class visible in Java is by using deftype with :volatile-mutable or 
:unsynchronized-mutable.
The only way to inherit from a concrete Java class is by using gen-class or 
proxy.  gen-class allows a single mutable field using :state and :init.
Thus there is no way to define a class that both inherits from a concrete 
class and defines more than one new instance variable.

I believe these statements are correct, but gen-class is complex and 
deftype use has some nuances, so I want to make sure I haven't missed 
something.

I know that I can use gen-class's state variable to hold multiple mutable 
structures by putting e.g. atoms inside of a map or record stored in the 
state variable, or by storing a deftype instance with mutable fields in the 
state variable.

(Context: I'm getting a meaningful performance boost by replacing atoms in 
a map or a record in a gen-class state variable, with deftype with 
:volatile-mutable in a gen-class state variable.  I keep wondering whether 
my gen-class class really needs to delegate to a deftype structure.  This 
is for an application that needs to extend one or more Java classes.  I 
know that :volatile-mutable and :unsynchronized-mutable are intended to be 
used only by experts.  I'm not an expert.  I've asked a question on 
StackOverflow 
http://stackoverflow.com/questions/30472496/risks-of-volatile-mutable-fields-in-single-threaded-contexts
 
about whether the particular way that I'm using :volatile-mutable, i.e. 
solely in single-threaded application, is safe.  Feel free to comment there 
or here on that issue, as well as on my main question above.)

Thanks.

-- 
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: Interop: mutability vs. inheritance

2015-05-27 Thread Marshall Bockrath-Vandegrift
Mars0i marsh...@logical.net writes:

 I believe these statements are correct, but gen-class is complex and
 deftype use has some nuances, so I want to make sure I haven't missed
 something.

You have missed one possible approach – write a small integration class
in Java which delegates behavior to a parameterized something more
easily expressed in idiomatic Clojure (e.g., an `IFn` function or
`reify`d interface).

I’ve made this joke before, but: Java is a pretty solid DSL for writing
Java classes.  When you need a Java class which conforms to some
combination of Java-side abstract signatures (extending a base class,
AOTed for discovery by name via reflection, annotations, etc), in my
experience it is frequently/nearly-always easier to adapt from that
interface to Clojure in Java that it is to adapt to that interface from
Clojure in Clojure.

Some examples:

https://github.com/damballa/parkour/blob/master/src/java/parkour/hadoop/Mappers.java
https://github.com/damballa/abracad/blob/master/src/java/abracad/avro/ClojureDatumReader.java

HTH,

-- 
Marshall Bockrath-Vandegrift llas...@damballa.com
Principal Software Engineer, Damballa RD

-- 
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: Interop: mutability vs. inheritance

2015-05-27 Thread Mars0i
Thanks--you're right, of course, Marshall.  (I almost added without 
writing it in Java somewhere in the first part of the post.  That doesn't 
mean writing parts in Java isn't worth considering.  I'm just trying to 
figure out what will and won't work in Clojure itself.)

-Marshall

On Wednesday, May 27, 2015 at 1:17:15 PM UTC-5, Marshall 
Bockrath-Vandegrift wrote:

 Mars0i mars...@logical.net javascript: writes: 

  I believe these statements are correct, but gen-class is complex and 
  deftype use has some nuances, so I want to make sure I haven't missed 
  something. 

 You have missed one possible approach – write a small integration class 
 in Java which delegates behavior to a parameterized something more 
 easily expressed in idiomatic Clojure (e.g., an `IFn` function or 
 `reify`d interface). 

 I’ve made this joke before, but: Java is a pretty solid DSL for writing 
 Java classes.  When you need a Java class which conforms to some 
 combination of Java-side abstract signatures (extending a base class, 
 AOTed for discovery by name via reflection, annotations, etc), in my 
 experience it is frequently/nearly-always easier to adapt from that 
 interface to Clojure in Java that it is to adapt to that interface from 
 Clojure in Clojure. 

 Some examples: 


 https://github.com/damballa/parkour/blob/master/src/java/parkour/hadoop/Mappers.java
  

 https://github.com/damballa/abracad/blob/master/src/java/abracad/avro/ClojureDatumReader.java
  

 HTH, 

 -- 
 Marshall Bockrath-Vandegrift lla...@damballa.com javascript: 
 Principal Software Engineer, Damballa RD 



-- 
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: Interop: mutability vs. inheritance

2015-05-27 Thread Tassilo Horn
Mars0i marsh...@logical.net writes:

 Is the following correct?

 The only way to define *multiple* mutable instance variables/fields
 for a class visible in Java is by using deftype with :volatile-mutable
 or :unsynchronized-mutable.  The only way to inherit from a concrete
 Java class is by using gen-class or proxy.  gen-class allows a single
 mutable field using :state and :init.  Thus there is no way to define
 a class that both inherits from a concrete class and defines more than
 one new instance variable.

I think that's correct (with the exception you already mention yourself:
you can use a :state structure containing multiple values).

 I know that I can use gen-class's state variable to hold multiple
 mutable structures by putting e.g. atoms inside of a map or record
 stored in the state variable, or by storing a deftype instance with
 mutable fields in the state variable.

If you care mostly about performance, maybe using an array as :state
will do.  That's always mutable and access is really fast.

Other than that, I agree with Marshall that Java is a solid DSL for
writing Java classes.

Bye,
Tassilo

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