Re: Generate exposers for ancestral fields

2008-09-17 Thread Matt Revelle
Posted a patch to traverse the class hierarchy looking for the  
specified fields, it also verifies that the field is protected.   
Exceptions are thrown if the field isn't found or is found but not  
protected.

Examples:

___A.java___
package pkg;

public class A {
 private String priv = a private member;
 protected String prot = a protected member;
 public String pub = a public member;
}


___B.java___
package pkg;

import pkg.A;

public class B extends A {}


___Generating class C, which extends class B and exposes protected  
field defined in class A___
user (gen-and-load-class 'pkg.C
   :extends pkg.B
   :exposes '{prot {:get getProt}})
pkg.C
user (.getProt (pkg.C.))
a protected member


___Generating class D, which extends class B and attempts to expose a  
field not found in the hierarchy___
user (gen-and-load-class 'pkg.D
   :extends pkg.B
   :exposes '{it {:get getIt}})
; Evaluation aborted.

:exposes references a field, it, that cannot be found
   [Thrown class java.lang.Exception]


___Generating class E, which extends class B and attempts to expose a  
private field defined in class A___
user (gen-and-load-class 'pkg.E
   :extends pkg.B
   :exposes '{priv {:get getPriv}})
; Evaluation aborted.

:exposes references a field, priv, that is not protected
   [Thrown class java.lang.Exception]


The patch can be found in the group's files section as exposers- 
hierarchy-traversing.diff.

My CA went out today.

-Matt

On Sep 16, 2008, at 1:06 PM, Rich Hickey wrote:




 On Sep 16, 11:12 am, Matt Revelle [EMAIL PROTECTED] wrote:
 Rich,

 Should I send in a CA and add ancestry verification and error  
 handling
 or is this an unacceptable change?


 I'm amenable to the idea, but I haven't looked at the specifics,
 holding off on changes pre-release. Please do send in a CA if you
 intend to submit patches. I wonder why specifying the ancestor class
 should be necessary, isn't it just a matter of finding the field in
 the hierarchy?

 Thanks,

 Rich


 On Sep 15, 12:22 am, Matt Revelle [EMAIL PROTECTED] wrote:

 I modifed clojure/genclass to support adding exposer methods for
 protected fields in classes higher up the hierarchy than the
 superclass.  Interfaces should also be supported too.

 The patch can be found 
 here:http://clojure.googlegroups.com/web/genclass_exposers.diff

 An example with the new syntax:

 (gen-and-load-class 'motive.visual.TestSimpleGame
 :extends com.jme.app.SimpleGame
 :exposes '{[com.jme.app.BaseSimpleGame rootNode]
 {:get getRootNode :set setRootNode}})

 The original exposes format is supported too, which defaults to the
 superclass.  There's currently no check done to verify that the  
 class/
 interface specified as the home of the field is a part of the
 hierarchy of the new class.  I'll likely add that and clean things  
 up
 a bit after I get some sleep and feedback.

 -Matt
 


--~--~-~--~~~---~--~~
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
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Generate exposers for ancestral fields

2008-09-16 Thread Rich Hickey



On Sep 16, 11:12 am, Matt Revelle [EMAIL PROTECTED] wrote:
 Rich,

 Should I send in a CA and add ancestry verification and error handling
 or is this an unacceptable change?


I'm amenable to the idea, but I haven't looked at the specifics,
holding off on changes pre-release. Please do send in a CA if you
intend to submit patches. I wonder why specifying the ancestor class
should be necessary, isn't it just a matter of finding the field in
the hierarchy?

Thanks,

Rich


 On Sep 15, 12:22 am, Matt Revelle [EMAIL PROTECTED] wrote:

  I modifed clojure/genclass to support adding exposer methods for
  protected fields in classes higher up the hierarchy than the
  superclass.  Interfaces should also be supported too.

  The patch can be found 
  here:http://clojure.googlegroups.com/web/genclass_exposers.diff

  An example with the new syntax:

  (gen-and-load-class 'motive.visual.TestSimpleGame
   :extends com.jme.app.SimpleGame
   :exposes '{[com.jme.app.BaseSimpleGame rootNode]
  {:get getRootNode :set setRootNode}})

  The original exposes format is supported too, which defaults to the
  superclass.  There's currently no check done to verify that the class/
  interface specified as the home of the field is a part of the
  hierarchy of the new class.  I'll likely add that and clean things up
  a bit after I get some sleep and feedback.

  -Matt
--~--~-~--~~~---~--~~
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
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---