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

Mon Jan 27 09:56:41 PST 2020

Hernan,

On Mon, Jan 27, 2020 at 6:44 AM Hernan Wilkinson <
hernan.wilkinson at 10pines.com> wrote:

> I was thinking today if adding the stop from compiling/removing a method
> would not be "over-design"...
> I mean, if a tool wants to stop a method from being compiled/removed,
> wouldn't it be responsibility of that tool?
> Let's say the file in wants to do that, then before compiling/removing a
> method it could check if it should do it or not for example.
> I know that having that feature in the meta-model sounds to be more
> "re-usable", but again I'm thinking if that is the case.
> In the case of announcing about changes I think it makes sense, it is a
> different use case and it proved to be useful
> Anyway, do not kill me! I is just a thought :-)
>

I'd have no problem with that approach if we made it easier to swap out the
various tools for other ones.  The problem currently is that people think
nothing about hard coding references to classes and casually adding a
dependency on yet another method in the class.  If we abstracted away the
class references and had more well defined APIs for interacting with each
of the tools, such as the Browser for example, I'd be fine with that.
(i.e. what you're proposing necessitates that I fork at least some of the
tools.  I'm OK if that's what we're saying is the way to go... just please
make it a bit more feasible to do without effectively forking the entire
image)

> Hernan.
>
> On Sat, Jan 25, 2020 at 12:01 PM Hernan Wilkinson <
> hernan.wilkinson at 10pines.com> wrote:
>
>> well... if you think that the "whole world" can do something different
>> that they can right now for the normal means... :-)
>> I mean, I understand your point but in Smalltalk anybody can do anything,
>> but I agree that the system change notifier was not meant for "asking", it
>> is just a notifier as its name says.
>> On the other hand, using the notifier to ask makes it less coupled, as
>> with the notifications...
>> Either solution is fine with me, each one has its pro and cons
>>
>> On Sat, Jan 25, 2020 at 11:31 AM Juan Vuletich <juan at jvuletich.org>
>> wrote:
>>
>>> On 1/24/2020 4:34 PM, Phil B via Cuis-dev wrote:
>>>
>>> I'm fine with that if that's what makes sense to everyone.  Ideally, the
>>> steps/stages I think we need to consider are 1) 'is it OK to do what I want
>>> to do?', 2) 'I'm about to do it', 3) 'it's done'.   3 is what we have
>>> currently.  1 & 2 could be collapsed into one step (the reason I did that
>>> with the #isOK* methods was that seemed to be consistent to how other parts
>>> of the image, such as Morphic, like to do similar things)  I'm currently
>>> mainly concerned with class and method changes but if there are other
>>> things we should be looking at doing this for, let's try to make sure we've
>>> considered them as well so we have a good solution.
>>>
>>>
>>> In general, I think it is ok to allow anybody to be notified of
>>> something about to happen and/or just happened. I'm not so sure if it is ok
>>> to allow anybody to prevent from (for example) a method being compiled.
>>> Telling the whole world seems ok to me. Asking permission to the whole
>>> world sounds like a bit too much. But I'm not sure at all...
>>>
>>> Thanks,
>>>
>>> --
>>> Juan Vuletichwww.cuis-smalltalk.orghttps://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Devhttps://github.com/jvuletichhttps://www.linkedin.com/in/juan-vuletich-75611b3
>>> @JuanVuletich
>>>
>>>
>>> On Fri, Jan 24, 2020 at 2:15 PM Hernan Wilkinson <
>>> hernan.wilkinson at 10pines.com> wrote:
>>>
>>>> With the SystemChangeNotifier (events), you can get notified que a
>>>> method was added, changed, removed, etc., but you can not stop
>>>> adding/changing or removing a method from happening. That is the difference
>>>> I see with what you propose.
>>>> We could "enhance" the system change notifier to add that
>>>> functionality, and I think that would be better because it is more
>>>> consisten with what the system does right now and it would not be coupled
>>>> with a class hierarchy and no redefinition of methods would be necessary.
>>>>
>>>> If you ask me, I would enhance the system change notifier
>>>>
>>>> Hernan.
>>>>
>>>> On Thu, Jan 23, 2020 at 6:56 PM Phil B <pbpublist at gmail.com> wrote:
>>>>
>>>>> A correction / clarification...
>>>>>
>>>>> On Thu, Jan 23, 2020 at 4:35 PM Phil B <pbpublist at gmail.com> wrote:
>>>>>
>>>>>> 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?
>>>>>>
>>>>>>
>>>>>
>>>>> What I was trying to say/ask was 'do you see anything that I can't
>>>>> functionally recreate from what I'd get from SystemChangeNotifier?'  (i.e.
>>>>> yes, there's a difference between the mechanisms but, unless I'm missing
>>>>> something, I think I can get what I need using SystemChangeNotifier)
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> *Hernán Wilkinson Agile 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
>>
>
>
> --
>
> *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/20200127/1e91c4bd/attachment.htm>