9

I've got a library written in F#, consumed by C# and F#. this library defines a class foo, in module bar, in namespace random:

#light
namespace random

module bar

type foo() = ...

Now, when I go to consume type random.foo.bar, C# intellisense sees it as type bar, nested in type random.foo.

The question is this: Is there an advantage to C# to define externally-consumable code into modules, rather than namespaces? I understand that modules are a good way to group functions, but what about classes?

CCovey
  • 799
  • 1
  • 10
  • 17
kolosy
  • 3,029
  • 3
  • 29
  • 48
  • Possible dupe, http://stackoverflow.com/questions/795172/what-the-difference-between-a-namespace-and-a-module-in-f – harms Jul 20 '09 at 19:37
  • 1
    sort of, but i was more looking for best practices for non-f# interop. that said, one is a corollary of the other. – kolosy Jul 20 '09 at 20:40

1 Answers1

16

If you're publishing F# components for consumption from other .Net languages, then you should avoid modules in the public interfaces, and stick to namespaces containing classes, structs, and enums.

(Modules are a handy way either to publish values, functions and types among F#-only components, or as 'internal' implementation details of an F# component that publishes .Net classes.)

(Do see also this question for a discussion of the 'technical distinction' between namespaces and modules. This question and my answer above are more about the 'intentional differences' e.g. when you would choose to use each.)

Community
  • 1
  • 1
Brian
  • 117,631
  • 17
  • 236
  • 300