You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am interested in using a version of Baum based on Traits. Baum looks well-featured, but we cannot use it by extending from it, because that would break our architecture.
At first glance, I don't really see a blocking issue to introduce Traits. In essence, all Baum\Node code should be moved into a separate Trait. You can then have Baum\Node use that trait, to provide backwards compatibility. If testing with instanceof is an issue, a Node-interface can be created to test on that interface.
In short, some refactoring is necessary to achieve the following pattern:
namespaceBaum;
interfaceNodeInterface {
// method signatures from Baum\Node
}
traitNodeTrait {
// implementation from Baum\Node
}
// only necessary for BCabstractclassNodeimplementsNodeInterface {
useNodeTrait;
}
I'm not really in a position to assess the amount of work involved, but it seems like a straightforward refactoring. And I do not see any drawbacks, as this will be BC and makes the library more flexible in use.
If you're open to my proposed change, I can do the modifications and create a PR.
The text was updated successfully, but these errors were encountered:
There's a whole other bunch of issues I need to look at, and as this is a BC, we'll probably get some more fixes / updates in place and bump the version to 2.0.
If anybody has any objections to this refactoring (and breaking change), please speak now, or forever hold your peace :-)
I am interested in using a version of Baum based on Traits. Baum looks well-featured, but we cannot use it by extending from it, because that would break our architecture.
At first glance, I don't really see a blocking issue to introduce Traits. In essence, all Baum\Node code should be moved into a separate Trait. You can then have Baum\Node use that trait, to provide backwards compatibility. If testing with instanceof is an issue, a Node-interface can be created to test on that interface.
In short, some refactoring is necessary to achieve the following pattern:
I'm not really in a position to assess the amount of work involved, but it seems like a straightforward refactoring. And I do not see any drawbacks, as this will be BC and makes the library more flexible in use.
If you're open to my proposed change, I can do the modifications and create a PR.
The text was updated successfully, but these errors were encountered: