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

[Phil B]

Juan,

On Thu, Jan 23, 2020 at 2:05 PM Juan Vuletich <juan at jvuletich.org> wrote:

> Hi Folks,
>
> (Hernán, I'm not answering your message, but Phil's original one
> because, although I share your curiosity and concerns, I want to answer
> in a rather orthogonal way)
>
> Phil, I think you are raising three completely different issues here
> (inline).
>

Fair enough.


>
> 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.
>
> Issue 1: Making the infrastructure for rejecting the compilation of a
> method more consistent, flexible and extensible. I'm no sure if your
> implementation is the best possible (because of Hernán's concerns, and
> because it is an ongoing discussion), but I think it is a good idea. If
> we can find a way to do it that makes everybody happy, let's go for it.
>

I'm by no means in love with the solution I came up with.  It mostly worked
and seemed to fit in with #noteCompilationOf:meta:.  If that's not how we
want to do things going forward, then my approach is a bad solution.

I don't have any particular preference of how it gets done, just anything
that gets us moving away from these embedded behaviors. It's typically just
a line or two for the behavior but they're embedded in key methods that
will change for other, unrelated reasons which cause my overrides to
break.  This is really my primary, and often only complaint, with some of
the recently added policies.  I'm fine that they exist in the image and can
see how they help some or even most users.  Just give me an easier, less
brittle way, to change or disable them if they get in my way.


> Issue 2: Allowing interested parties to be notified of changes to code.
> Here I don't think we need a new mechanism. We already have
> SystemChangeNotifier. See senders of #methodAdded, #methodChanged and
> #methodRemoved . I think it is better to use this, and keep enhancing it
> as convenient.
>

I'm OK with that assuming there's no way to (easily/inadvertently) bypass
the mechanism.  I was only using #noteCompilationOf:meta: because you
pointed me toward it years ago and never got the memo that we were
changing. (I suspect you pay closer attention to changesets than I do :-)
However, it only provides half of what I'm looking for (i.e. after the
change has been made)

I suspect the other half will probably come with whatever provides the
solution to issue 1: whatever mechanism says 'yes, it's OK to do this'
could also be used to serve as notification of 'this change is about to
happen'


>
> > 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)
>
> Issue3: Inconsistencies in existing code. WRT #noteCompilationOf:meta: ,
> I'd just remove it. Users should use SystemChangeNotifier anyway. Other
> inconsistencies you see in the code should be discussed and fixed.
>

I'm OK with that.


>
> 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/20200123/1441a3c0/attachment-0001.htm>