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

Hernan Wilkinson hernan.wilkinson at 10pines.com
Wed Jan 22 01:37:15 PST 2020


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 :-)
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.
2) Why would not only redefine #compile:... and #removeSelector: for the
classes that you need that behavior? (it is related with 1) and I think I
know what your answer will be, but I ask just in case :-) )
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"
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?

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?

Cheers!
Hernan.

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


More information about the Cuis-dev mailing list