Delegate Types Action, Func and Predicate ?

[mainhatten]

Hi,
currently mentally searching for alternative ways to implement GetWordCount/GetWordNum better.
One avenue I had tried before was to declare the specific type of delegate, which in C# can be
- Action (fancy name to return void or being command-like)
- Func (Should have realized earlier that this bites with xBase 4-Letter abbreviation of "Function")
- Predicate (fancy name for returning a Boolean)

And check out ways to add or combine them.

Code: Select all

BEGIN NAMESPACE XSharp.VFP
    /// action  __DoOnChar(tc2Check as Char)
    ///* predicate __IsInDe(tc2Check as Char)
    Delegate __IsInDelimiterArray(tc2Check as Char) as Boolean
    Delegate __GetWordCountActive(tcString AS STRING) as Long
    Delegate __GetWordNumActive(tcString AS STRING, tnWordNum as Int) as String

which errors on the commented lines. Also "Predicate" not found in xSharp docs.
To be honest: I am not really fond of thinking more along those lines, as it
a) quickliy leads into LINKish structures
b) calling as Delegates has shown measurable performance hit, which I'd rather avoid if possible (could be me not writing best code)

so please just indicate if xSharp supports {Action, Func, Predicate} and if so, what is the syntax for them ?
If they are NOT supported, this is NOT a request to support them ASAP - just knowing that this is not supported as of now is enough, and if I really think I need to try that avenue, I could try via C# directly, to get an idea if IMO xSharp misses something valuable.
More/better Vfp implementation more important near this keyboard

If implementation needs nothing more strenuous than adding 3 new keywords and their mapping to C# keywords implementing them "en passant" might still be useful for those used to C# (or reading up on Dotnet concepts described in C# docs for newbies like me)

regards
thomas

[Chris]

Hi Thomas,

Yes, they are all supported, see small sample below. Regarding Func, you need to prefix it with "@@", which instructs the compiler and editor to not treat it as a keyword, but as an identifier instead:

Code: Select all

FUNCTION Start() AS VOID
LOCAL oMultiply AS Action<INT,INT> // 2 int params
oMultiply := { n AS INT , m AS INT =>
			System.Console.WriteLine(n * m)
			}
oMultiply(3,4)

LOCAL oIsEven AS @@Func<INT,LOGIC> // 1 int param, logic return type
oIsEven := { n AS INT =>
			RETURN n % 2 == 0
			}
? oIsEven(3)

But why are you thinking to use those, why are they better in your case than normal procedural code?
Btw, sorry I have not yet replied to 2 of your previous threads about VFP functions, I want to do a bit more research on them myself and will get back to you.

[wriedmann]

Hi Thomas,
they are supported in X#, and I have used at least Action and Predicate in my own (WPF) applications.
This is a piece of code:

Code: Select all

self:ImportButton := RelayCommand{ ExecuteImportButton, ExecuteEnabledButtons }

whereas the constructor of the RelayCommand class is

Code: Select all

constructor( oExecute as Action<object>, oCanExecute as Predicate<object> )

and the relative methods are

Code: Select all

public method ExecuteImportButton( oObject as object ) as void

Code: Select all

public method ExecuteEnabledButtons( oObject as object ) as logic

Wolfgang

[mainhatten]

Hi Chris and Wolfgang,
thx for the pointers. Yupp, you way of coding also works with my 1-step back Bandol, did not find the fitting syntax, as I was trying to define a pre-typed delegate to be used in more than 1 place instead of typing always the data type again. Current top of progam clearly compiles, but line, defining method Test_Type, is the one most DRY in my eyes.

Code: Select all

    /// action  __DoOnChar(tc2Check as Char)
    /// predicate __IsInDe(tc2Check as Char)
    /// predicate __IsInDe<Char>
    Delegate __IsInDelimiterArray(tc2Check as Char) as Boolean
    Delegate __GetWordCountActive(tcString AS STRING) as Long
    Delegate __GetWordNumActive(tcString AS STRING, tnWordNum as Int) as String
	/// <summary>
    /// The Class1 class.
    /// </summary>
	CLASS GetWordHandler
        public oDelFunc as @@Func <Char, Boolean>
        public oDelActn as Action <Char, Int>
        public oDelPred as Predicate <Char>
        public oDelType as __IsInDelimiterArray

        internal method Test_Type(tcString as String, isInDelimiter as __IsInDelimiterArray) as String
            return ""
            
        internal method Test_Func(tcString as String, isInDelimiter as @@Func<Char>) as String
            return ""
            
        internal method Test_Pred(tcString as String, isInDelimiter as Predicate<Char>) as String
            return ""            

I will test if passing delegate as parameter or setting as local Func-var makes measurable difference in Runtime - Guessing that yes, an effect can be seen, but not remarkable enough to keep from recoding in traditional ways mostof times only overloading IsInDelimeter.

But why are you thinking to use those, why are they better in your case than normal procedural code?
Btw, sorry I have not yet replied to 2 of your previous threads about VFP functions, I want to do a bit more research on them myself and will get back to you.

Will answer that one over on other thread, as it touches topics raised there. Will be a few answers, each to 1 topic, as hectic here today.

regards
thomas

[wriedmann]

Hi Thomas,
these things are working for years now - I'm using them for at least 2 or 3 years now.
They are implemented at the compiler level, so they work also in Core dialect without any runtime.
Wolfgang

[mainhatten]

these things are working for years now - I'm using them for at least 2 or 3 years now.
They are implemented at the compiler level, so they work also in Core dialect without any runtime.

Hi Wolfgang,
I did not mean
"I have to test if this runs after compiling without error"
but meant
"I will test if a delegate passed as parameter (or set as Local Var) incurs the same runtime penalty as a delegate class member"
Class members are supposed to slower than Locals, but that is NOT the effect I am hoping to see.
A class member could be modified by rogue code at least from own unsafe methods even if declared protected:
Checking Type safety not only on assign, but on method call might be sensible.
Checking Type safety ONCE on calling with delegate parameter might make similar sense, as does when assigning local delegate.
CALLING those delegates in the same function and always doing a safety dance I would call unneccessary (If that really IS the reason for the 5-10% slowdown veryfied by Chris as well).

My experince in Dotnet is rather dated (some C# and IronPython when Hugunin had freshly released), I have to translate C# documentation into correct xSharp and this is not by reflex as of now.
Also (being somewhat of a perf nut) I want to gain a similar "gut knowledge" on what goes how fast in xSharp, as I realize that my well-honed "vfp instincts" will lead me astray here sometimes...
I know the danger of premature optimization - I am looking for "automatic dismissal of really bad patterns" I have to learn in Dotnet.

regards
thomas