[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ivy-dev
Subject:    Ivy refactoring - step 4
From:       "Xavier Hanin" <xavier.hanin () gmail ! com>
Date:       2007-02-02 8:53:07
Message-ID: 635a05060702020053p6b08118s5bdc8d638af8587b () mail ! gmail ! com
[Download RAW message or body]


Hi All,

I've worked on the refactoring of the IvyNode class, I'm not completely
satisfied with the refactoring, but I begin to be exhausted by refactorings
:-)

Let's say that what I've done is an improvement, but the IvyNode class is
still too big and difficult to understand. Anyway, there is a progress (I
hope you will see that as a progress :-)), maybe I make further refactorings
in this class later when I'll recover from this intensive refactoring
experience ;-)

So, in a few words, what I've done is split the IvyNode class in several
classes. First, I've created a new class, VisitNode, which represents a
visit of a node of the dependency graph. Before IvyNode was used to store
both data of the node and data relative to the current state of the visit
(from which parent do I visit the node, in which root module conf, and so
on). Now IvyNode do not store this kind of data any more, it's the
responsibility of VisitNode (which stores an instance of the IvyNode
visited, and delegates several methods to IvyNode to offer an API quite
similar to IvyNode one in 1.4).

Besides this split, I've extracted two responsibilities from IvyNode: caller
management (who depends on me, now handled by IvyNodeCallers class) and data
related to conflict management (now handled by IvyNodeEviction class).
IvyNode now delegates to instances of these classes for these features.

Ok, I think I'll stop the refactoring for the moment, feel free to give
feedback! What I still plan to do soon (next week I think) is to refactor
the Ivy API as I've done for deliver (see my mail on refactoring step 3),
but I'll wait for feedback for that.

- Xavier


[prev in list] [next in list] [prev in thread] [next in thread]