The problem with Function Signatures

So I was reading Stefan Tilkov’s latest post, about link and self.

Good stuff.

Now the bit that prompted this post was his discussion of the possibility of having different representations of the same thing.

For example you could easily get three representations of the same Customer:

  1. With their Address
  2. With a link to their Address
  3. With nothing


This is fine and generally doesn’t cause any trouble.

Until that is, you try to define functions that operate on these resources as if all three representations are exactly the same.

Perhaps by creating a C# method something like this:

public void SendBookToCustomer(Book book, Customer customer)

Familiar isn’t. We all write stuff like this.

Notice that nothing about this signature tells the caller what is ‘really’ required.

I could easily pass any of the 3 representations of a customer to this function, and my code would compile.

But would it work?

In this case because of the name of function I can deduce that the function need’s the Customer’s Address:

So the function probably expects (1). Or relies on the Customer object itself being able to compensate for (2) by doing O/RM style lazy-loading.

Of course this is all just speculation.

Maybe the function needs nothing, and has access to advanced resource resolution capabilities?

Maybe the function will ignore the address passed in, assuming it could be stale?

We just don’t know.


This is why things like hyperdata / and lazy-loading is so important.

A signature alone is not enough to help me call functions.

Particularly when the target function is called from somewhere with different context, data availability, and trustworthiness.

Hmm… lots of questions

PS: starting to solve this problem seems like a pre-requiste of truly Composable Services.

Comments (0)

Skip to main content