RE: re: TrueType font support and 3.6

Hi Daniel,

> Do we disagree on the code, on the software engineering rule of thumb,
> on its application to this code, or on its application to 
> Squeak code in general?

We disagree on the terms "flaw" and "error". The issues you originally
mention may (depending on ones interpretation, certainly not mine - see
below) be seen as "flaws" but there are definitely no "errors" in what you
describe. None of them (not a single one) will prevent Squeak to function
correctly.

> I don't see what this has to do with beta

It has a whole lot to do with beta. If alpha is closed without the TTF stuff
it means you've delayed the most important improvement to Squeak's user
interface in the last three years. For reasons which I find impossible to
follow.

> I also never required that conflicts be checked with "all 
> ongoing work" - MCP is part of Squeak 3.6 as of 5240, IIRC.
> Conflicts with previously included work should be detected
> and resolved, of course - when we don't
> do this, we get the annoying "didnt I fix this already" effect.

Are you aware that right now this is almost impossible? For example, I've
posted the declarative pools at SqueakMap and there are a few conflicts with
KCP changes. Fixing these conflicts means that suddenly noone in pre-3.6
systems can load this any longer. So how do you propose to proceed in this
situation?

I'd argue that what we want to do is to load the existing code base and fix
the conflicts as things get integrated. This leaves the package at SqueakMap
alone and will allow others to use it, too.

[snip]
> On the other hand, the work hasn't been done yet to bring it up
> to the desired quality level.

Desired by whom? Looking at your critique in detail:

>  - at least one method clashes with MCP.

It's not "at least" one method but "exactly" one method and the conflict is
that some "verb first" has been reverted to "verb at: 1".

>  - The single GrafPort method sends to super but
> implicitly returns self.

I don't get the point here. Why can't a method send to super and implicitly
return self? In any case, it seems that this method is just a left-over from
later improvements.

>  - Paragraph>>asForm does an "isKindOf: TTCFont"

Again, what's your point here? Paragraphs have to know fonts or else they
can't function correctly. One can argue that using isKindOf: is generally
not good style (and I agree on this) but in this particular case the action
taken is so specific for TTCFonts that it makes perfect sense to use
#isKindOf:.

> Claim I - We have a piece of code that's candidate for inclusion. We all
> agree it has flaws as detected by even cursory inspections.

No, we don't "all agree". That's my point. If you consider the above to be
serious flaws that need to be fixed then please explain to me what the
"desired code quality" is that you are trying to achieve. To me, this is
nit-picking.

Cheers,
  - Andreas