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

Thu Jan 23 13:00:02 PST 2020

Hi Phil!

On Wed, Jan 22, 2020 at 2:56 PM Phil B <pbpublist at gmail.com> wrote:

> Hernan,
>
> On Wed, Jan 22, 2020 at 4:37 AM Hernan Wilkinson <
> hernan.wilkinson at 10pines.com> wrote:
>
>> Hi Phil!,
>>  it is interesting what you are proposing. I'd like to understand a
>> little bit more the motivation, why you did it that way, etc., so I have a
>> few questions :-)
>>
>
> Before addressing your specific questions, it might be helpful for me to
> clarify where I'm coming from a bigger picture standpoint:  I don't like
> how hard coded and brittle much of the infrastructure in Smalltalk is.
> I've complained about it before so this should come as no surprise ;-) This
> is a small step towards addressing one aspect of this.  We have
> #noteCompilationOf:meta: and no one seems to mind so I thought 'why not
> extend it so we can have more of a lifecycle view of methods?'  While it's
> far from a Smalltalk MOP implementation that Alan Kay has talked about,
> using a mechanism like this seems to me a better approach than either
> needing to override a number of inconvenient methods and/or baking in
> features other people many not want to avoid doing said overrides rather
> than just reacting to method changes as desired.  So by adding a few more
> hooks around method creation/removal, I can get the functionality I need
> without either making someone else's life more difficult or my own.
>

I agree :-)
There is the events mechanism to announce about changes in methods,
classes, etc., but you can not stop a change for happening with that for
example, and your proposal is more oriented to the CLOOS MOP.

>
>
>> 1) Do you have a real case scenario for this feature? I'd like to know
>> the use that we could give it. I would like other peoples opinion on this
>> too because it is a change in the core.
>>
>
> Of course! (I never proposes changes that I don't have a need for ;-)
>

:-)

> The main categories of use cases I have in mind are:
>
> 1) One wants to track senders or implementors of arbitrary methods at an
> aggregate level.  These can be relatively expensive things to compute,
> especially in bulk.
>
> 2) One wants to keep metadata of particular senders/implementors of a
> method in sync/updated as the image changes.  Some of this metadata may
> alter the behavior in other parts of the image, including potentially
> regenerating/recompiling code elsewhere.
>
>
I'd like to mention that this two things can be solved using the events
infrastructure.

> 3) Allow for (partially) fixing one of my long standing gripes about the
> image (see my response to your #3 below)
>
> One of the things I'm continually running into is that the runtime
> structure of the image is just too brittle.  Sure, you can dynamically
> add/remove methods, but the mechanism for having other code react to these
> changes in realtime, and/or at a global level, is lacking.  This is what
> these proposed additions are attempting to address.
>
>
> 3) Why do you signal an error if compilation is not allowed? That is
>> changing the contract of #compile:... and I'm not sure that an exception is
>> what users of #compile... would expect in that case. Also, in the case of
>> not removing a method you do not signal an exception making the behavior of
>> "not doing" kind of "inconsistent"
>>
>
> You are correct that an error was the wrong way to do it and that an
> exception would be better... I'm fine with changing that.  However, I'm not
> going to let you take both sides of the argument re: the rest... :-)
>

oh! when I said exception I meant any kind of exception. An error is an
exception for me :-)
I'm not sure a specific exception would help... what I mean is that
currently #compile:... does not throw an exception/error when something
fails, it returns nil. I'm not saying that it is better! just that it
changes the behavior of #compile:...
Also, I'm thinking in a situation where I use the #isOkToCompile to return
false when loading code, let's say because the method is trying to compile
already exists. An error will be signaled when there is actually no error
involved and currently #compile:... returns nil for similar situations.
I think that if #isOkToCompile returns false, #compile:.. should return nil

>
>
>> 4) The redefinition of #isOkToCompile:meta, #isOkToRemove:meta: and
>> #noteRemovalOf:meta: in Object class are not necessary, as far as I can
>> see, why did you redefine them there?
>>
>
> I was following the lead of the #noteCompilationOf:meta: Object override
> here.  This is related to my query related to #removeSelector: that
> follows...
>
>
>>
>> About your question of #removeSelector:, I don't quite understand you
>> question, I think you are missing the meta class part there. I mean, I you
>> have class XX and it has a class method, let's say #m1 and you want to
>> remove it, you have to do:
>> XX class removeSelector: #m1
>>
>> The method that will be evaluated for that message send will be the one
>> implemented in ClassDescription, as with a class because Metaclass and
>> Class are subclasses of ClassDescription.
>> Does it make sense what I'm saying? or am I not understanding your
>> question?
>>
>
> Apologies, I didn't state the question/issue very well...
>
> Look at where the implementors for #noteCompilationOf:meta: and
> #removeSelector: are.  For #removeSelector: the ClassDescription
> implementor gets called for instance methods, Behavior for class methods.
> Yet for #noteCompilationOf:meta: it's ClassDescription for instance methods
> and Object (per the method comment) for class methods.  I was expecting
> more symmetry here (i.e. #noteCompilationOf:meta: essentially being a
> method add/change and #removeSelector: being method removal) and wondering
> if there was a reason they ended up where they did or if no one has really
> thought about it before?  So that's why I put those methods in Object: it
> seemed like they *should* be needed and functional there. (i.e. I did note
> the class-side problem ;-)  I don't really care where they go, but the
> add/change/remove methods probably should go there together.
>

I see... the #noteCompilationOf:meta: in Object class is not needed either
as far as I understand it.

I think this functionality is interesting, I would add it making the change
of #compile:... (not signaling an exception) and without the implementation
in Object class (I would remove #noteCompilation... from Object class too).

Juan, what do you think?

Hernan.

>
>
>> Cheers!
>> Hernan.
>>
>
> Thanks,
> Phil
>
>
>>
>> On Sat, Jan 18, 2020 at 8:08 PM Phil B via Cuis-dev <
>> cuis-dev at lists.cuis.st> 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)
>>> --
>>> Cuis-dev mailing list
>>> Cuis-dev at lists.cuis.st
>>> https://lists.cuis.st/mailman/listinfo/cuis-dev
>>>
>>
>>
>> --
>>
>> *Hernán WilkinsonAgile Software Development, Teaching & Coaching*
>> *Phone: +54-011*-4893-2057
>> *Twitter: @HernanWilkinson*
>> *site: http://www.10Pines.com <http://www.10pines.com/>*
>> Address: Alem 896, Floor 6, Buenos Aires, Argentina
>>
>

-- 

*Hernán WilkinsonAgile Software Development, Teaching & Coaching*
*Phone: +54-011*-4893-2057
*Twitter: @HernanWilkinson*
*site: http://www.10Pines.com <http://www.10pines.com/>*
Address: Alem 896, Floor 6, Buenos Aires, Argentina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20200123/78991cdd/attachment.htm>