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
>>
>
>
>
>