I'm unsure as to why I originally placed them in separate methods. propParse() will
always find a getter at the same time it finds a setter, and vice versa, should they
both have been defined on the object.
Finally feels like things are starting to come together.
It's rather interesting looking back. Each time I begin writing a piece of
software, I think to myself, "This is the best way to do it." Well, generally.
Perhaps the implementation could have been better, but I may not have had the
time. However, the general concept remains.
Each time I look back months later and find that I disagree with certain
decisions. I find certain implementations to be messy or poorly constructed. Or
perhaps I was just being lazy to begin with. Whatever the case, it is
comforting. It shows that one is continuing to learn and evolve.
Now, in the case of ease.js, we're working with a number of different factors in
regards to my perception of prior code quality. Primarily, I'm looking at a
basic implementation (in this case, I'm referring to test cases) that served as
a foundation that could be later evolved. I didn't have the time to devote to a
stronger solution. However, since the project has evolved so far past my
original expectations, a more sophisticated solution is needed in order to
simplify the overall design. That is what happened here.
Of course, we're also looking at a year's worth of additional, intimate
experience with a language.
Regardless of the reason, I love to see software evolve. Especially my own. It's
as if I'm watching my child grow. From that, I can get a great deal of
satisfaction.
One shouldn't expect perfection. But one should certainly aim for it.
Ironic, considering the current refactoring (not yet committed) of MemberBuilder to split validation logic into MemberBuilderValidator was partially to be able to easily override the fallback logic. It's a useful refactoring nonetheless, but it could have waited.
As mentioned in a prior commit blog-like entry, many of the tests evolved into more of an integration or system-level type of test. Let's get away from that.
This is the first test case to use the new basic xUnit-style system. This
system is likely to evolve over time. Right now it's purely for
setUp, organizational and output purposes.