se˝ior ┐tyrtle? wrote:
> On 7/24/05 8:05 PM, "Julian Foad" <email@example.com> sneezed:
>>numbers beginning with a "minus" sign will not be recognised as numbers.
>>You'll say that's "just a bug" but that's far from the only problem,
> What the hell is that? An ad hominem?
Er, no. I didn't mean it as such; sorry if it sounds like it. All I meant
was, "Look, here's an example of how the type-guessing code doesn't necessarily
guess the type that people might expect it to in a particular situation; after
you fix this one, there are bound to be many other such cases, because the
rules are not clearly defined."
I was criticising the code from the point of view of whether it represented a
clean, concisely documentable design, suitable to be a long-term part of the
software, and asserting that in this regard it didn't. I was purposefully
ignoring the fact that it does what you want it to do today, as that's not very
relevant to whether it is suitable for inclusion in the project.
Again, I'm sorry if I offended you. I intended only to give a technical review.
> This really soured me on the rest of the message, some of which is just as
> bad. From my first mail on this subject (second rev of the patch) I've been
> completely open that parsing this data is somewhat nefarious, and that it is
> grounds for rejection.
Right, I did see that, and should have commented on it straight away. I got a
little confused by that remark, as during a review cycle people usually try to
modify their patch in such a way as to make it _less_ likely to be rejected :-)
(Hey, don't hit me - I'm jost poking friendly fun at you, smiling as I write
this, while trying to give you a hint as to how I misunderstood your position
on the (lack of) importance of that part of the code!)
I hope I'm now understanding correctly that you more or less threw that extra
stuff into that iteration of the patch to see what discussion it would provoke,
or just because you were working on it and it was easier for you to leave it in
than take it out, and that you were more or less expecting to have to take it
> You stated your reasons why you thought it was a bad
> idea, which honestly, I already knew. When I state my reasons why I think
> it isn't -so- bad, I'm labeled some sort of obstinate bastard?
Me? Would I ever say a rude thing like that? I might have been thinking it,
though :-) To me it sounded like you were arguing that the benefits outweighed
the objections. Sorry for misunderstanding.
> For my purposes I -need- this type information, so it will be the first code
> I write. There's no -need- for me to submit this patch, I'd like to.
And I'm glad you did want to submit it.
> I think I've been more than amiable; writing a DTD for a spec I thought
> would be rejected, fixing formatting mistakes, patching to trunk, compiling
> with gcc (for this rev) to catch these stupid errors my compiler is missing,
> and even changing my beloved font...changing my font man!
Heh, the font! I hope you're starting to grow fond of your new one already.
Seriously, thanks for sticking with it and doing all of those things to create
a patch that complies with the project's guidelines.
> I'm perfectly fine with writing a tool to do this separate from Subversion,
> I just think it's beneficial to discuss options/scenarios, and to present,
> what is as of now, the only real-world needs of this code...at least once.
It seems we had a bit of misunderstanding between "Here's a patch that ought to
be ready to commit" and "Here's a patch that demonstrates some ideas that might
> Fixed group_props_xml_rev to properly return an error code.
> Not even begrudgingly removed type guessing code.
Thanks. I'll review this patch in a separate message.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Mon Jul 25 05:29:03 2005