Hide this comment

Yes, given that mutually recursive classes must all go in one file, if you want to break such code up into multiple files, you must either

  • redesign to break the dependencies (so there is less coupling/cohesion among the classes)
  • refactor to introduce interfaces as a point of indirection, so the light interfaces are coupled but the heavy implementations are decoupled

Both strategies may have other side-benefits you might appreciate.

(A future version of F# is likely to introduce a new language construct that allows recursive groups to span multiple files or namespaces.)

By on 6/7/2010 9:31 AM ()Reply
Hide this comment

Why not just ditch the OO way of designing your code and go completely functional. which would mean using records to build your datastructures and declaring the operations that operate over those datastructures as functions.

By on 6/7/2010 3:33 PM ()Reply
Hide this comment

Why not just ditch the OO way of designing your code and go completely functional. which would mean using records to build your datastructures and declaring the operations that operate over those datastructures as functions.

Because OO and encapsulated private data are good things, and because member functions are more discoverable than free functions.

Abandoning OO is a bad idea. Use FP in the small, but the original poster is clearly thinking 'in the large'.

See also:

How does functional programming affect the structure of your code?

By on 6/7/2010 4:09 PM ()Reply
Hide this comment

Maybe you can try and abstract away the bits that make those types dependent on each other. Put them into a separate class, then you have independent types that can go into separate files.

It may not be this easy in your case though.

By on 6/7/2010 7:55 AM ()Reply
IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy
Built with WebSharper

Logging in...