thats correct. It scans assemblies looking for classes marked with a special attribute - then loads MethodInfo objects from those classes into a structure that the eval code can reference later - where it now uses the currenttype in EvaluateFunction and ValidateFunction. The scanning for methods part is pretty much done - I'm just hooking it up to your EE code - I'll probably have a couple of questions as I work thru that.What does your "custom function loading code" do? I presume that you want to load functions from external dlls and make them available to EE.
I was thinking of namespaces as well. I had in mind a slightly different idea. To use attributes to mark a class as containing custom functions somthing like:This brings me an idea: as the number of functions EE supports will grow, we're going to need a concept similar to namespaces and impose some structure on the naming of functions to be consistent.
[CustomFunctionSet(NameSpaceUri="somenamespace", prefix="foo" )]
public class BuiltInFunctions : CustomFunctionSetBase {
public BuiltInFunctions(Project project) : base(project){
}
// function definitions
public void SomeFunc(){
}
}
and then the scanning would just pick this up rather than requiring the user to specify it. I'm allowing functions to be imported from the same assemblies that are currently scanned for tasks ie those in the nant bin dir. Then any extra libs can be added using somthing like the <loadfunctions> task you describe below. Maybe <loadfunctions> could override namespace defined with the attribute to prevent duplicate namespace usage if necessary.
Do you think the functions need to be defined as static ? I was thinking of making them public instance and passing a Project instance to the containing objects constructor so that functions can have access to various information inside the project - the same as tasks can now. It might be worth marking each method with a [NAntCustomMethod] attribute so that you can more finely control which methods get exported as functions.
hmm - not sure about the casing. Current nant standard is for lower case element and attribute names but no such restraints apply to attribute values. Should we just use the .Net casing standards in this case ?
Ian
I suggest that we leave string and conversion functions as they are now (they are kind-of "core"), but change names of all other functions by prefixing them with their functional area:
round(v) -> math.round(v) floor(v) -> math.floor(v) ceiling(v) -> math.ceiling(v) abs(v) -> math.abs(v)
getcreationtime(filename) -> file.creationtime(filename) getlastwritetime(file) -> file.lastwritetime(filename) getlastaccesstime(file) -> file.lastaccesstime(filename); fileexists(file) -> file.exists(filename) filesize(file) -> file.size(filename)
now() -> date.now datediff(d1,d2) -> date.diff(d1,d2) dateadd(d1,seconds) - date.add(d1,d2)
Assuming you'd have cvs functions, they would be placed in "cvs" namespace
cvs.getfilerevision(filename) cvs.ismodified(filename) cvs.isbinary(filename)
The function loading code should place loaded functions in a separate namespace. So could load functions like this:
<loadfunctions assembly="AAA.dll" type="Functions" prefix="aaa" /> Assuming class Functions contains:
public static int testme(string a,int b,DateTime c) { }
It sould be accessible as: "aaa.testme()" not "testme()". <loadfunctions> shouldn't allow you to load functions into a global namespace.
Another question: should function names be case sensitive? Should they be upper-, lower- or mixed case ? pascal casing (File.CreationTime()), camel casing (File.creationTime()) or linux casing (file.creation_time)?
Jarek
------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
