Recap from the previous two posts
In the last two posts we saw a way to generate dependencies between files like this: if a method call is made, the file where that call happens depends on the file where the method is defined. And that dependencies are transitive because of how Crystal works.
Then we saw that the file dependencies graph is quite messy for real programs and that changing one file usually affects most of the other files.
An observation
After writing the last post I realized there's something slightly wrong in the way dependencies, and more precisely transitive dependencies, are tracked.
Consider the following files:
# foo.cr
require "bar"
def foo
bar
end
foo
# bar.cr
require "baz"
require "qux"
def bar
baz
qux
end
# baz.cr
def baz
1
end
# qux.cr
def qux
"hello"
end
Doing a dependencies graph for the above program gives this:
So bar.cr
depends on both baz.cr
and qux.cr
.
If we change the method qux
to return an int, bar
will start retuning an int, and so foo
will start returning an int: transitive dependencies doing their stuff.
BUT, and this is the important bit, if we change the method baz
to return a different type, no matter what type, and no matter how many changes we do to it, we do need to re-compile and re-analize bar
, but it doesn't affect foo
because baz
is not being used as a return value of bar
.
That means that the messy dependencies graph we have so far might not be that messy after all. And also, that we have two graphs: direct dependencies and transitive dependencies.
When we checked the method IO#<<
and saw that it calls obj.to_s
, so io.cr
depends on whatever type we give to IO#<<
, the method definition is this:
class IO
def <<(obj) : self
obj.to_s self
self
end
end
But note that the obj.to_s
call isn't part of the return type. That means that, yes, if the file where the type of obj
changes we need to recompile io.cr
, but it doesn't mean we have to recompile files that depend on io.cr
.
Computing actual transitive dependencies
Now, the main issue is determining which method calls affect the return type.
For example, consider this:
def foo
x = bar
x
end
Here the method returns x
, and x
came from a call to bar
, so foo
transitively depends on bar
. So we have to keep track of how variables came to exist, and their dependencies. Luckily the Crystal compiler already keeps track of this to actually compute the type of x
, so in theory this should be easy to do.
Another example is this:
def foo
qux
if something
bar
else
baz
end
end
Here the last expression in the method is an if
, so the actual dependencies of foo
are bar
and baz
, but not qux
.
Another dependency that might not be easy to see is call arguments. For example:
def foo
bar(baz(1))
end
Here foo
depends on bar
. But does it depend on baz
? Well, if baz
suddenly changes and returns a different type, another overload of bar
might be hit that returns a different type, and so foo
might start returning a different type. So it seems that call arguments need to be taken into account.
What's next?
I'll need some time to code this and get it right. Once I do that I'll post my findings. Will the dependencies graph be leaner? Will we find happiness? Will it make us cry? Stay tuned!
Top comments (1)
Did you get to the bottom of this?
Was really excited about the Lucky Framework until I ran into some extreme compile times.
I'll take any excuse to come back to Crystal. I think it's great.