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