<div dir="ltr"><div><div><div><div><div><div><div><div>Also remember that we have to move all methods that read/write fonts and image out of graphics;<br>otherwise it depends on a bunch of packages (system, files, ...).<br>
<br></div>Note that graphics was focused on BitBlt graphics.<br>But this is only one possible backend (Pharo is developing alternate ones).<br></div>Though, the font scanning is independent of BitBlt (well, there is one specialized subclass for rendering on BitBlt).<br>
</div>Thus, in term of modularity these two things could be split eventually (BitBltGraphics depending on Text scanning).<br></div>Pharo has grouped text things together (both description and scanning). Don't know if it is a good idea though...<br>
<br></div><div>Anyway, I find those classification really limited.<br></div><div>As emphasized thru the discussions there is more than one classification possible.<br></div><div>For example, you might want to see Array both in Collections and Kernel.<br>
<br></div><div>Those classifications are like file system: they do not match our need/brain.<br></div><div>We want something that can be queried like a database.<br><br></div>So sometimes, I wonder if we shouldn't have class/methods belonging to several packages.<br>
</div>The class/method would be removed only when all it's parent packages have been removed.<br></div>You could then remove Collections without removing Array, because Array is also in Kernel.<br></div><div>I feel like such feature could avoid balkanization of packages.<br>
</div>Or maybe it's the most stupid idea...<br>We should push it a bit to see how it goes...<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">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>
<span class="HOEnZb"><font color="#888888"><br>
frank<br>
<br>
</font></span></blockquote></div><br></div>