Forum Discussion

MarkRoddy's avatar
MarkRoddy
Visitor
16 years ago

Semantics of Comparing Functions

I admit this is a bit of an esoteric question, but I ran into a situation where I was comparing two functions and would like some clarification.

Through from some experimentation I've deserned the following:

'Grabbing 'pointers' to existing functions
x = SomeFunction
y = SomeFunction
(x = y) = True

'Single Anonymous Function
x = Function ( )
Return 1
End Function
y = x
(x = y) = True

'Two Anoymous Functions
x = Function ( )
Return 1
End Function
y = Function ( )
Return 2
End Function
(x <> y) = True

'From an "object"
obj = CreateSomeObject()
x= obj.Function1
y = obj.Function1
(x = y) = True

'Different functions from same "object"
'From an "object"
obj = CreateSomeObject()
x= obj.Function1
y = obj.Function2
(x <> y) = True

'Same function on different "objects"
obj1 = CreateSomeObject()
obj2 = CreateSomeObject()
x = obj1.SomeFunction
y = obj2.SomeFunction
(x = y) = True


This all seems to make sense, but none of it is documented from what I can find. The ifFunction interface only lists the GetSub() and SetSub() functions (nothing in regards to comparison), and there are no details on the semantics of equality listed out.

Can I consider the above equalities stable, or are they likely to change in the future?

-Mark

4 Replies

  • Mark

    I don't forsee these semantics changing....

    Just curious, what code are you writing that relies on this?

    --Kevin
  • It's kind of a long story. I'm working on brstest (new release this weekend, I swear), which examines source files to find test fixtures (which are really just function). I have some tests place which executes the inspection code to see if returns a reference to the expected function. The comparison is done by using a function 'assertEqual()'.

    Previously, assertEqual() was something along the lines of:
    Sub assertEqual(val1, val2)
    If val1 <> val2 then
    m.DoSomethingToHandleTestFailure()
    End If
    End Sub

    This was fine for strings, floats, ints, and apparently functions, but I wanted to extend it to handle other more common data types (lists, dictionaries, arrays, etc). So what I did was write a comparison function for each 'type', built a dispatch table mapping the string identifier of the type to the function that does the comparison, and add an addition function which does the dispatching (this is how my previous question on the dot operator came up). When I put this in place the test described above started failing as the dispatch table didn't have an entry for roFunction objects. This was pretty easy to add (since all it takes is an '=' comparison), but I wanted to confirm the semantics of function comparison before I did my next release.

    -Mark
  • Thanks for the explanation Mark. That makes sense.

    I hope developers are getting good use out of your test framework.

    You're certainly pushing the bounds of the BrightScript language.... keep it up!

    --Kevin
  • Thanks Kevin. And I was just thinking after I posted this that you guys must be getting sick of me and my super obscure questions 🙂

    -Mark