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

[Phil B]

Hernan,

On Thu, Jan 23, 2020 at 4:00 PM Hernan Wilkinson <
hernan.wilkinson at 10pines.com> wrote:

> 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.
>

True, but I was only using the MOP as the inspiration.  I'm not pushing for
it as the 'be-all, end-all' approach.  If we want to say that the events
mechanism is how I'll get the post-change notifications and either we'll
extend the notification mechanism or come up with something else for the
pre-change notification/approval, I'm OK with that.


>
>> 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
>

As I indicated in my response to Juan, I don't have any strong feelings as
to how we do this.  Only that we do it.  Any place we have code preventing
the user or code from making some change to the image (such as
adding/changing/removing a class or method), let's instead have a more
generalized mechanism that allows for rejecting the requested change and
putting that code there instead.  That way if I want different or more/less
strict restrictions from someone else, I can get that without causing them
problems and vice versa.


> 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.
>

That may have changed over the years... pretty sure it was needed way back
when (I think Juan might have added it after I complained about not getting
some method changes)


>
> 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).
>

Other than being a composite of #methodAdded, #methodAddedInProtocol and
#methodChanged messages, do you see any functional difference from what I'd
get from SystemChangeNotifier?


>
> Juan, what do you think?
>
> Hernan.
>

Thanks,
Phil

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20200123/a0728a0d/attachment.htm>