[Squeakfoundation]re: TrueType font support and 3.6

Daniel Vainsencher danielv at netvision.net.il
Sat Jun 21 22:28:05 CEST 2003


> 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.
You don't, but Yoshiki agrees. I have no ideas what issues he is working
on, and what their intersection is with the ones I raised but he's
stated that we shouldn't integrate the current version. 

I don't consider the above to be "serious flaws". I consider the above
to be the kind of small cruft that naturally accumulates when building
something, and gets easily cleaned out *before* it gets integrated and
forgotten, so that we don't one day need a TTFCP. You think this is nit
picking, I think code should be clean as it can reasonably be. The price
to clean it today is tiny compared to the price paid by everyone that
will try to maintain the code in the future.

> 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.
Have you ever failed a test because you didn't put in the effort and had
to do it over? did you blame the teacher for writing the test? 

You may see things so that you think that I'm delaying this code, but
this code could easily be cleaner, and you know it, and you can do
something about it just as easily as me. As for my role in this, I don't
agree that welcoming cruft into Squeak arbitrarily is the way to advance
it.

I think this is clearly about values, and maybe about that "Vision" you
were looking for so hard - I think Squeak's code should be something
that people enjoy reading. I think much of the power Smalltalk has had
over Smalltalkers' ideas comes from teaching them by example "this is
how it should be". Cruft in the Basic Squeak image sabotages that
effect, and makes Squeak weaker in something that really matters. I'm
going over to a friend whom I'm teaching Smalltalk, we'll be looking at
squeak code, and he'll be asking "why did they do that?" with all
intention to learn something new. And I'll say to him, "Oh, no, ignore
that, some people think it's ok to let cruft into the image (but look at
the beautiful fonts it gives us!). Here, look at this bit, this one is
good... well mostly".

[Conflicts are hard to find]
Well, yes. Do you think that the fact that conflict detection is hard
means that we should ignore it? We can do the work at integration, or we
can be surprised later by problems in releases newbies use. This extra
work is the price of distributed development. The problems of unchecked
conflicts will get worse with more contributors. BTW, feel free to try
out and improve Dougs conflict checker.

[DecPools and KCP]
The fact that conflicts with packages are hard to solve is a sad
consequence of not having package releases. It is made more difficult by
having more packages, but the solution is not in going back to a
monolithic image, but in improving our infrastructure (SM1.1). Wish I
could give you a release date for that, but I can't. When we're talking
about a package, like RB, what I did was fork it into two packages. When
we're talking about a patch like DecPools, I would track the current
alpha, because the version for an old 3.6 won't be particularly useful
to anyone.

Daniel

Andreas Raab <andreas.raab at gmx.de> wrote:
> 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
> 
> _______________________________________________
> Squeakfoundation mailing list
> Squeakfoundation at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/squeakfoundation


More information about the Squeakfoundation mailing list