<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Nov 28, 2013 at 2:37 PM, Nicolas Cellier <span dir="ltr"><<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><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></div></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>That's not a problem is it? Surely System and Files are lower-level than graphics? If the core system is some form of headless REPL then having Graphics depend on System and Files is fine. Otherwise one should split Graphics into e.g. Graphics-Core and Graphics-Development (or Deployment vs Development, etc) where the stuff to create fints etc is in Graphics-Development whch can be unloaded for deployment.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div>
<div><div>Note that graphics was focused on BitBlt graphics.<br></div>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=""><div class="h5"><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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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><font color="#888888"><br>
frank<br>
<br>
</font></span></blockquote></div><br></div>
</div></div><br><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div>
</div></div>