On Fri, 4 May 2012, Tony Gravagno wrote:
> It's been a while since I have looked at MVSP but as I recall there
> wasn't a MVString in the original release, simply because they're just
> passing around delimited strings. MVString seems to have been added
> just for the convenience of parsing the strings. Well, anyone can do
> that. I created a small library of .NET extension methods to get all
> of the functionality not present in the core library. (Never had time
> to publish this or my documentation *sigh* ) For Java, let's assume
> the MVString class is "anemic", I'd start by creating a subclass with
> whatever functionality they're missing, and just use that. I don't
> have my code open but as I recall I did that for a few MVSP .NET
> functions anyway where I found bugs.
>
> I know you're just trying to determine if you're missing something,
> and I know you can do all of this on your own. I'm speaking half to
> you and half to the group.
>
Thanks Tony. I'd love to see your MVSP stuff some time - email me
off-list about it. I'm heavily involved in .Net and D3.
It astonishes me that they'd go to the effort of creating the library and
then go and do such a half-assed job at it. Yeah, I could sit down and
subclass it, but Raining Tiger (I _loved_ that Jon!) should step up to the
plate and finish the fskcing thing. I barely have enough time to write my
own code let alone fix unacceptable deficiencies(sp!!) in a commercial
product. I should have expected this considering the pure stupidity of
the Insert bug that was in the .Net library. The most cursory of testing
would have discovered that particular problem. I swear, their idea of
unit testing must involve unzipping their pants, going "Yep, got a unit!"
and then moving on. :)
A Multi-Value database for the masses, not the classes.