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