I would like to make some pods, but there would be a circle in dependencies. This would force me to put everything into one large pod. I know I can put the code into separate folders, but for the system and the fandoc it will become one large flat pod. I would like somehow to make separate packages of it as I would have been able in java.

Are there any solutions to this problem.

---

This is just an crazy idea, but should be possible at least in javascript.

If I would be able to to do the following thing I would not need the circle dependencies.

pod b -> dependent on pod a

pod a has Class A pod b has Mixin B

pod b has a "indication" when its gets "loaded" that class A implements mixin B.

So when only pod a is loaded the definition is like

Class A

but when pod b is loaded the definition becomes

Class A implements Mixin B

Well the entire system is designed to explicitly prevent circular dependencies :-)

It does take some work to create a proper dependency graph, although in some cases it is also easy to cheat using reflection, meta-programming, and the "->" operator.

Can you talk about the actual types and design you are trying to figure out?

I am implementing the DOM interfaces.

So i have my base dom2 pod(dom -> name already used), which holds the interface Document

The Document interface implements DocumentCSS, SVGDocument, DocumentEvent, SMILDocument mixins. But these mixins are in seperate pods, which are dependent on my dom2 pod. So I would like that Document starts implementing DocumentCSS as soon as the css pod is imported/used.

Well assuming one sub-class, it would be:

domCss::DocCss extends dom2::Doc

But you actually want something like this:

dom2::Doc implements domCss::DocCss + domSvg::DocSvg

That would be true cyclical dependency if Doc actually tried to rely on explicit methods and functionality in the sub-pods. But I think your idea is that dom2 doesn't actually know about or even stub out abstract/virtual slots for the CSS, SVG, Event functionality right?

That would be a good use for true traits where they could be mixed at object creation time:

combo := new(DocCss, DocSvg, DocEvent) // made up syntax

But it sounds like the only reason for combining them is the convenience of someone using all of them further down in the dependency chain right? These guys don't actually need to know about each other. In that case I might use delegation:

docCss::DocCss  : docPart::DocPart
docSvg::DocSvg  : docPart::DocSvg

docAll::Doc
{
  const DocCss css := DocCss()
  const DocSvg svg := DocSvg()
}

That would give you a diamond dependency tree:

|     docPart 
|        |
|    +---+---+
|    |       |
|    v       v
|  docCss   docSvg 
|    |       |
|    +---+---+
|        |
|        v
|      docAll

It would be a solution to mix them at object creation time, but is currently not possible in fantom.

But it sounds like the only reason for combining them is the convenience of someone using all of them further down in the dependency chain right? That is indeed true.

But for example Document implements mixin DocumentEvent, which has the following function

abstract Event createEvent(Str eventInterface)

The problem is that the class Event comes from the pod event and is so unknown in pod dom2. I could put in the docAll where it is known, but how can I then let a field/function inside the svg pod return a docAll.

A class defenition like would solve my problem

@Js
mixin DocumentEvent
{
  abstract Event createEvent(Str eventInterface)
}

//Say that Document now implements DocumentEvent
Document +: DocumentEvent

I think it should be possible to implements and would somehow nice to have, but I know that it probably will bring also all kind of other problems with it and it might be something unwanted. But we can make a new discussion out of it, if you think it worse to have it.

There is a formula to solve circular dependencies

|            A  <--->  B

                  |
                  v

|                          C
| A ---> B&IA    or       / \
|                        /   \
|                       /     \
|                      A'      B'
|                       \     /
|                        \   /
|                         \ /
|                          D

IA is a interface of A.