Of course one can sometime get into a circular dependency using this pattern of code structuring. (e.g. if one has two functions in different areas that might need each other.)
Elm is pragmatic. If *a good case* for splitting the code in multiple files can be made, it might implement that. On Fri, Jul 8, 2016 at 6:27 PM, Robert Walter <[email protected]> wrote: > Hi Peter, > > thank you again, this is a great reference. > Would you agree that, while your solution is pretty flexible, it is not > equivalent to a feature which would allow one to spread out a module to > several files. Don't get me wrong, I really like your example and how it > illustrates the capabilities of aliases and imports to unify several > modules under a common interface, but due to the imports, it is a bit more > restricted and wouldn't allow one to have "function a" in ModuleName.A and > "function b" in ModuleName.B and call those function from the other module. > > I don't have a particular use case where something like this is required > and I think the option you highlighted covers most use cases where you want > to separate a large module into several smaller ones, so thanks again! > Robert > > On Friday, July 8, 2016 at 2:31:09 PM UTC+2, Peter Damoc wrote: >> >> I've created some sample code starting from the Counter Example >> >> https://github.com/pdamoc/elm-assistance/tree/master/MultiFile >> >> Please take a look. >> >> >> >> >> On Fri, Jul 8, 2016 at 2:14 PM, Robert Walter <[email protected]> >> wrote: >> >>> Thanks Peter for showing these options. >>> In both cases, however, the modules themselves wouldn't be able to share >>> types, for example. I could think of a "physical" separation of a module's >>> code like so: >>> >>> src >>> |_ moduleName.model.elm >>> |_ moduleName.view.elm >>> |_ moduleName.update.elm >>> >>> Where I define type aliases and types in "moduleName.model.elm" and >>> where I can access those in the other files (given that they all are part >>> of the same module). Maybe I'm missing something? >>> >>> >>> On Friday, July 8, 2016 at 11:03:23 AM UTC+2, Peter Damoc wrote: >>>> >>>> If you want you can break a module into multiple files and offer a >>>> unified interface. >>>> >>>> I can think of two ways to do this. >>>> >>>> 1. with folders, where you push all the module files into its own >>>> folder and add that folder to the "source-directories" in elm-package.json. >>>> 2. with prefixing/suffixing in file names / module names. >>>> >>>> In both cases the pattern is the same, you create aliases: >>>> >>>> module ModuleName exposing (first, second, third) >>>> >>>> import ModuleName.First >>>> import ModuleName.Second >>>> import ModuleName.Third >>>> >>>> first = ModuleName.First.first >>>> >>>> second = ModuleName.Second.second >>>> >>>> third = ModuleName.Third.third >>>> >>>> >>>> If it helps, you can think about the actual ModuleName as playing the >>>> role of __init__.py in a python module. ;) >>>> >>>> >>>> >>>> On Fri, Jul 8, 2016 at 11:48 AM, Robert Walter <[email protected]> >>>> wrote: >>>> >>>>> Hello, >>>>> >>>>> as far as I can tell, it is a requirement that a module names matches >>>>> its file name, which means that one cannot split a module into several >>>>> files, correct? >>>>> I'm curious about the rational behind it? Is it "just" so that the >>>>> compiler has an easier time resolving imports or are there other reasons >>>>> as >>>>> well? >>>>> >>>>> One could argue that it forces users to keep things that belong >>>>> together logically also physically together and that it encourages you to >>>>> keep modules small. On the other hand, message communication between >>>>> modules seems to be a bit unwieldy which makes me hesitant to create too >>>>> big of a module hierarchy. From a beginner's point of view, I like the >>>>> idea >>>>> of "partial module" declarations, but I can imagine that there are good >>>>> reasons against that. >>>>> >>>>> best, >>>>> Robert >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Elm Discuss" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> >>>> >>>> -- >>>> There is NO FATE, we are the creators. >>>> blog: http://damoc.ro/ >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Elm Discuss" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> There is NO FATE, we are the creators. >> blog: http://damoc.ro/ >> > -- > You received this message because you are subscribed to the Google Groups > "Elm Discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- There is NO FATE, we are the creators. blog: http://damoc.ro/ -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
