Re: Namespace loading with defrecord and attempting to call unbound fn

2013-04-16 Thread Pierre Allix
Thank you the patch works.

I though it would have made sense to just create a record directly from 
Java since they can implement Java interfaces.

On Monday, April 15, 2013 7:57:28 PM UTC+2, Meikel Brandmeyer (kotarak) 
wrote:

 Hi Pierre,

 does this patch work?

 8--8--8
 diff --git a/test/eu/markosproject/test/LicenseCheckerTest.java 
 b/test/eu/markosproject/test/LicenseCheckerTest.java
 index 2e017cc..1a1cc82 100644
 --- a/test/eu/markosproject/test/LicenseCheckerTest.java
 +++ b/test/eu/markosproject/test/LicenseCheckerTest.java
 @@ -11,8 +11,12 @@ import 
 eu.markosproject.commons.interfaces.licensing.ICheckerResultStorer;
  import eu.markosproject.commons.interfaces.licensing.IRNotification;
  import eu.markosproject.licensing.LicenseChecker;
  
 +import clojure.lang.RT;
  
  public class LicenseCheckerTest {
 + static {
 + RT.var(clojure.core, require).invoke(RT.var(clojure.core, 
 symbol).invoke(eu.markosproject.licensing));
 + }
   
   private final static Logger log = 
 Logger.getLogger(LicenseCheckerTest.class .getName()); 
   
 8--8--8

 I'm not convinced that records are supposed to be created directly. (Ok. 
 Testing. Maybe.) They should be an implementation detail returned by an 
 API. If you need Java access there you might want to still go the Clojure 
 route and provide Java access through a façade. cf. Rich Hickey's example 
 of Datomic: 
 http://skillsmatter.com/podcast/scala/impromptu-rich-hickey-lightning-talk

 Meikel



-- 
-- 
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/groups/opt_out.




Re: Namespace loading with defrecord and attempting to call unbound fn

2013-04-16 Thread Meikel Brandmeyer (kotarak)
Hi,

Am Dienstag, 16. April 2013 11:32:38 UTC+2 schrieb Pierre Allix:

 Thank you the patch works.

 I though it would have made sense to just create a record directly from 
 Java since they can implement Java interfaces.


As a rule of thumb, I go with the non-AOT behaviour of Clojure. In that 
case the record does not exist until the namespace is required. So if I 
want to use it (in particular directly from Java), I have to require the 
namespace upfront to actually create the record class. And even if AOT 
would behave differently (think gen-class: require implementing namespace 
on class init), doing it explicitly is more robust because it allows both - 
AOT and non-AOT - usage.

But as I said before: I would not create the record directly but go through 
the support functions (-Bar, map-Bar). Or even higher level 
constructing functions. In Java this is probably the factory pattern.

Meikel

-- 
-- 
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/groups/opt_out.




Re: Namespace loading with defrecord and attempting to call unbound fn

2013-04-15 Thread Meikel Brandmeyer (kotarak)
Hi,

reading the resources you linked, I got the impression that just the 
initial require is missing. Instead of adding the require to the method, it 
should be added to the application init (or some appropriate static 
initializer? The class giving out instances of the record might be a 
candidate.). That should be sufficient. However there was no complete code 
demonstrating the issue. Only the clojure side. So I may be missing 
something.

Behaviour like for gen-class is not implemented, yet, AFAIK.

Meikel

-- 
-- 
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/groups/opt_out.




Re: Namespace loading with defrecord and attempting to call unbound fn

2013-04-15 Thread Pierre Allix
Hi Meikel,

If you look at the source of this project:

git clone git://git.berlios.de/markos-license-analyser

in the test directory there is a JUnit test where the Clojure record
is instantiated through a normal Java 'new' call.
The record is imported with a normal Java import.

If you want I could create a project reproducing the bug.


On Apr 15, 1:33 pm, Meikel Brandmeyer (kotarak) m...@kotka.de
wrote:
 Hi,

 reading the resources you linked, I got the impression that just the
 initial require is missing. Instead of adding the require to the method, it
 should be added to the application init (or some appropriate static
 initializer? The class giving out instances of the record might be a
 candidate.). That should be sufficient. However there was no complete code
 demonstrating the issue. Only the clojure side. So I may be missing
 something.

 Behaviour like for gen-class is not implemented, yet, AFAIK.

 Meikel

-- 
-- 
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/groups/opt_out.




Re: Namespace loading with defrecord and attempting to call unbound fn

2013-04-15 Thread Meikel Brandmeyer (kotarak)
Hi Pierre,

does this patch work?

8--8--8
diff --git a/test/eu/markosproject/test/LicenseCheckerTest.java 
b/test/eu/markosproject/test/LicenseCheckerTest.java
index 2e017cc..1a1cc82 100644
--- a/test/eu/markosproject/test/LicenseCheckerTest.java
+++ b/test/eu/markosproject/test/LicenseCheckerTest.java
@@ -11,8 +11,12 @@ import 
eu.markosproject.commons.interfaces.licensing.ICheckerResultStorer;
 import eu.markosproject.commons.interfaces.licensing.IRNotification;
 import eu.markosproject.licensing.LicenseChecker;
 
+import clojure.lang.RT;
 
 public class LicenseCheckerTest {
+ static {
+ RT.var(clojure.core, require).invoke(RT.var(clojure.core, 
symbol).invoke(eu.markosproject.licensing));
+ }
  
  private final static Logger log = 
Logger.getLogger(LicenseCheckerTest.class .getName()); 
  
8--8--8

I'm not convinced that records are supposed to be created directly. (Ok. 
Testing. Maybe.) They should be an implementation detail returned by an 
API. If you need Java access there you might want to still go the Clojure 
route and provide Java access through a façade. cf. Rich Hickey's example 
of 
Datomic: 
http://skillsmatter.com/podcast/scala/impromptu-rich-hickey-lightning-talk

Meikel

-- 
-- 
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/groups/opt_out.