For the immediate thing you asked, +1


2013/11/28 Frank Shearar <frank.shearar at gmail.com>

> On 28 November 2013 22:37, Nicolas Cellier
> <nicolas.cellier.aka.nice at gmail.com> wrote:
> > Also remember that we have to move all methods that read/write fonts and
> > image out of graphics;
> > otherwise it depends on a bunch of packages (system, files, ...).
> >
> > Note that graphics was focused on BitBlt graphics.
> > But this is only one possible backend (Pharo is developing alternate
> ones).
> > Though, the font scanning is independent of BitBlt (well, there is one
> > specialized subclass for rendering on BitBlt).
> > Thus, in term of modularity these two things could be split eventually
> > (BitBltGraphics depending on Text scanning).
> > Pharo has grouped text things together (both description and scanning).
> > Don't know if it is a good idea though...
> >
> > Anyway, I find those classification really limited.
> > As emphasized thru the discussions there is more than one classification
> > possible.
> > For example, you might want to see Array both in Collections and Kernel.
> >
> > Those classifications are like file system: they do not match our
> > need/brain.
> > We want something that can be queried like a database.
> >
> > So sometimes, I wonder if we shouldn't have class/methods belonging to
> > several packages.
> > The class/method would be removed only when all it's parent packages have
> > been removed.
> > You could then remove Collections without removing Array, because Array
> is
> > also in Kernel.
> > I feel like such feature could avoid balkanization of packages.
> > Or maybe it's the most stupid idea...
> > We should push it a bit to see how it goes...
>
> That's an interesting idea, and I wouldn't mind exploring it... at a
> later time :) Right now I want to solve a much smaller problem :)
>
> frank
>
> > 2013/11/28 Frank Shearar <frank.shearar at gmail.com>
> >>
> >> One way in which Graphics depends on System is through the resumable
> >> exception FontSubstitutionDuringLoading. StrikeFont class >>
> >> #familyName:size: uses it to signal that a font family is missing, and
> >> ProjectLoading uses it to record missing fonts.
> >>
> >> The relationship is entirely reasonable, but problematic from a module
> >> point of view: it entangles a low level package (Graphics) with a mid-
> >> to high-level package (System).
> >>
> >> I propose the following:
> >> * rename FontSubstitutionDuringLoading to MissingFont.
> >> * Update the three references to MissingFont.
> >> * move MissingFont to Graphics.
> >>
> >> This preserves the behaviour, but suggests what the problem is rather
> >> than under what circumstances the problem appears. More importantly
> >> though, it means that Graphics depends that much less on System.
> >>
> >> Thoughts?
> >>
> >> (This has the side effect of removing the problems that I reported
> >> yesterday regarding not being able to see all users of
> >> FontSubstitutionDuringLoading - the new MissingFont literals are all
> >> ClassBindings. However, note that during the class rename I didn't see
> >> all the places I needed to change, presumably because of the
> >> Alias/ClassBinding discrepancy.)
> >>
> >> frank
> >>
> >
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131128/3288dfe4/attachment.htm