<div dir="ltr"><br><div class="gmail_extra"><br>Craig wrote:<div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> If we have the raw class dependency data, why do we anything else?<br>
> And we may very well find that the groupings expressed by PackageInfo<br>
> (class category) stuff are wrong anyway...</blockquote><div><br></div><div>Frank replied:</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Well, because PackageInfo is what we have right now. But the<br>
</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
counterargument, for what it's worth, is "then let's correct the<br>
PackageInfo data until they do make sense as modules".</blockquote><div><br></div><div>The system is too big to look at all the class-level dependencies all at once. Even just looking at package dependencies, Tobias had to simplify the graph to be able to get meaningful insights. Of course, to actually break the dependencies, yeah, we'll have to go down to the level of classes and methods. But the high-level overview can help us sort out priorities.</div>
<div><br></div><div>Also, note that PackageInfo and class categories aren't the same thing. Packages can include extension methods on classes not in the package, and exclude extensions that belong to other packages. It's true that examining the system via class category doesn't make a lot of sense, but that's not what we're doing here.</div>
<div><br></div><div>Colin</div></div></div></div>