<div dir="ltr"><div dir="ltr">Juan,</div><div><br></div>OK, that's basically what I was thinking.   I just wanted to see if you were open to it first since it will require some rework (I'm not currently thinking a rewrite is in order... we'll see) of the existing model classes.  I'll start with the model and if the direction makes sense then can enhance the views to expose the functionality.<div><div><div><br></div><div>Thanks,</div><div>Phil</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Nov 2, 2019 at 1:35 PM Juan Vuletich <<a href="mailto:juan@jvuletich.org">juan@jvuletich.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 10/29/2019 2:17 PM, Phil B via Cuis-dev wrote:<br>
> I was looking into adding the ability to easily analyze/diff two <br>
> sources of Smalltalk code (i.e. basically the same image vs. changeset <br>
> or image vs. package functionality we currently have but expanding the <br>
> capability to allow for any two arbitrary sources whether changesets <br>
> vs. changeset, package vs. package, package vs. changeset or some <br>
> other pairing entirely) and it seems a bit harder than it needs to be <br>
> since the existing implementation assumes you will always be comparing <br>
> the image vs. something else.<br>
><br>
> If this already exists and I'm looking in the wrong place, pointers <br>
> are appreciated.  If it doesn't, would there be any objection to <br>
> modifying/cleaning up this code so that we could optionally set an <br>
> 'other' Code*Browser that would be used rather than always assuming <br>
> the image?  A related enhancement could be to make the Code*Browser <br>
> code a bit smarter so that we don't need to explicitly determine if <br>
> 'this is a package' or 'this is a changeset' unless you want to.  <br>
> Basically I'm asking if we would be willing to trade a (slight) <br>
> increase in implementation complexity for increased code source <br>
> flexibility here?<br>
<br>
Hi Phil,<br>
<br>
What you want is not yet done. I think it is a good idea. I suggest <br>
writing new (or improving existing) Model classes, for code already <br>
loaded in the image (in base image or in packages), and for code in <br>
files (CodePackageFile, etc). Ideally, the same View classes (i.e. the <br>
Morphic Windows) should be the same and work on whatever model. Models <br>
should be polymorphic enough so that comparing works irrespectively of <br>
the models involved.<br>
<br>
This could be a nice improvement for the system.<br>
<br>
Cheers,<br>
<br>
-- <br>
Juan Vuletich<br>
<a href="http://www.cuis-smalltalk.org" rel="noreferrer" target="_blank">www.cuis-smalltalk.org</a><br>
<a href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev" rel="noreferrer" target="_blank">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev</a><br>
<a href="https://github.com/jvuletich" rel="noreferrer" target="_blank">https://github.com/jvuletich</a><br>
<a href="https://www.linkedin.com/in/juan-vuletich-75611b3" rel="noreferrer" target="_blank">https://www.linkedin.com/in/juan-vuletich-75611b3</a><br>
@JuanVuletich<br>
<br>
</blockquote></div></div></div></div></div>