[Cuis-dev] Expanding on #noteCompilationOf:meta:

[Phil B]

Juan,

It's going to take me a bit to get my code migrated (I was using
#noteCompilationOf:meta: as well as a few other methods that were
removed... no big deal, I just need to refresh my memory as to what my code
is doing and why)  I'll followup as soon as I've got everything converted
and tested.

As far as the final paragraph, I think it's a moot point with
#noteCompilationOf:meta: going away.  I was mainly wondering why some of
the methods were at different places in the class hierarchy vs. the
#removeSelector: methods.  But with one going away entirely, it doesn't
really matter anymore... :-)

Thanks,
Phil

On Wed, Jan 29, 2020 at 8:55 AM Juan Vuletich <juan at jvuletich.org> wrote:

> On 1/18/2020 8:07 PM, Phil B via Cuis-dev wrote:
> > Attached is a first cut of something I've wanted for a while: the
> > ability to capture method changes as they occur with the ability to
> > prevent them from happening if needed at a global level.  Basically
> > it's just paired methods of #isOkTo[Compile|Remove]:meta: and
> > #note[Compilation|Removal]Of:meta:.
> >
> > It's always bothered me how central the method  structure is yet
> > completely useless from the standpoint of having extensible
> > metadata... if I'm wrong re: extensibility, please let me know what
> > I've overlooked.  So barring that, these changes allow for things like
> > helping to keep a separate metadata structure in sync with method
> > changes.  The main requirement is to be able to track method adds,
> > changes and deletes to the image globally.  Not sure, but I was
> > thinking that this facility might also be useful for refactoring tools.
> >
> > One issue / odd thing I noticed: the removal methods only get called
> > instance-side due to ClassDescription #removeSelector: only getting
> > called on instance methods and you have to jump up to the Behavior
> > implementor for class methods.  That seems strange to me since method
> > compilation all appears to occur at the level of ClassDescription.  Is
> > there a reason removals need to be different from compilation in this
> > way?  (Not knowing the answer, I haven't fixed this issue in the
> > attached changeset)
>
> Hi Phil, folks,
>
> This is my proposal.
>
> When reviewing all this code, I found some dead code, and stuff crying
> for cleanup. Hence the attached #4035 and #4036.
>
> Then, I almost cloned your implementation of isOk, but with a different
> question for adding a new method than for modifying en existing one. I
> did #4037 with your initials, as it is your code after all.
>
> BTW, I don't quite get your last paragraph. Can you elaborate a bit on
> the issue, perhaps with steps to reproduce the offending behavior?
>
> If these changesets look ok for everybody, I'll push them to GitHub.
>
> Thanks,
>
> --
> Juan Vuletich
> www.cuis-smalltalk.org
> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
> https://github.com/jvuletich
> https://www.linkedin.com/in/juan-vuletich-75611b3
> @JuanVuletich
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20200130/707b4184/attachment.htm>