> El 31 ene 2024, a las 15:36, Marcus Denker <marcus.den...@inria.fr> escribió: > > For both #isAbstract and #initialize, one can understand both as cases where > we have to use behavior for something that should actually be a kind o > declarative property of the objects. > > - isAbstract > > This is a property of the class. > > - initialize > > This is a property of the Variable. It’s really unfortunate to have to fall > back on code execution for that. What the initalize does is to say
There is out there indeed code that uses class side initialize methods to initialize class variables to constants. But that is not the only case. Some class side initalizes have complex initializations. Some are used to register the loaded class to some registration mechanism. > >> On 31 Jan 2024, at 15:03, Noury Bouraqadi <bouraq...@gmail.com> wrote: >> >> This is indeed an issue I'd like to see solved. >> Class initialization is just an instance of a more general isssue. >> In SUnit, defining abstract classes is dirty. The code often looks like this >> MyTestClass class>>#isAbstract >> ^self == MyTestClass >> In PharoJS we face the issue of class specific methods. Upon transpiling to >> JS, we want to perform some actions for some classes and not their >> subclasses. >> A possible solution is to introduce class specific properties through an >> extra-layer of metaclasses. Yes, I agree. I would like to have two levels of “Metaclasses”. Actually, one metaclass that is the traditional metaclass defining the class behavior. One “companion” object where we can define domain concerns. The companion object should respect the double hierarchy, but it will not class anymore with the meta-behaviour in the class! We will be able to freely program there without mistakenly overriding critical behavior from classes :). And we will be able to define metaclasses with really specific behavior for a single class in the hierarchy chain. G
