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

[Hernan Wilkinson]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20200125/a2a6ad93/attachment.htm>