Christoph Thiede Jan 10, 2023

I'm not sure whether I should love or hate this common pattern in @squeaksmalltalk @st80:

Smalltalk allClassesDo:
[:ea |
(ea class includesSelector: #fancyUpdate)
ifTrue:
[ea fancyUpdate]].

It feels weird to me that I need to duplicate a method in a metaclass' subclass to make sure it receives the message. Is this even object-oriented? At least, it is not class-oriented, the method dictionary is an internal of the class object. Still, the pattern is pretty convenient to use …

Show threadTobiasSep 20, 2023
@LinqLover @squeaksmalltalk @st80 There's `#respondsTo:` and `#canUndertsand:`
But I think, depending on the update path, you want to make *sure* that a class only receives a message it understand.
This is very similar to why you don't `super initialize` in a class.
Show threadChristoph Thiede Sep 20, 2023

@krono @squeaksmalltalk @st80 No, #canUnderstand: also checks the superclass which is undesired behavior in the pattern I mean. Yes, class-side initialize is another instance of this.

I guess this problem comes from the shared nature of classvars. When I normally delegate to super on instance side, I do not have to fear that this will affect state meant to be managed by another object. Maybe the world would be a better place if we only had inst-side and class-side instvars ... (1/2)

Show threadTobiasSep 21, 2023
@LinqLover @squeaksmalltalk @st80 We *do* have class-inst vars, always had.
The problem is not the vars, but the dual-nature of Class objects.
They, are indeed, instances of metaclasses and as such normal objects, but they are also meta-objects to their non-meta actual objects. And singletons, too.
/
Show threadTobias
@LinqLover @squeaksmalltalk @st80 With that come that the superclass (or super-meta-object) hierarchy is not one of shared *nature*. Just because you initialize "MyClassFoo class" there is no indication why you should run the initializing routines of "Object class" again (which potentially resets stuff in your class object).
I'd bet this is similar to your update routines.
Sep 21, 2023 at 5:22amWeb
Show threadChristoph Thiede Sep 21, 2023
@krono @squeaksmalltalk @st80 But this advice comes from the perspective that classes have (among others) classvars instead of only instvars, right? My point is, if we did not have the concept of class vars, sending "super initialize" on the class side would be perfectly fine - and maybe actually good style, because any instvars defined on "Object class" would have to be initialized for the separate "sub-meta-object" "MyClassFoo class" again indeed.
Show threadChristoph Thiede Sep 21, 2023
@krono @squeaksmalltalk @st80 (Subsuming #allInstances/#allSubInstances to the mental model of instvars/classvars for the discussion...)
Show threadTobiasSep 21, 2023
@LinqLover @squeaksmalltalk @st80 Waaaait, (sub)instances and inst/classvars are extremely different beasts!
Show threadChristoph Thiede Sep 21, 2023
@krono @squeaksmalltalk @st80 Really? Apart from the VM magic for enumerating objects, I would have thought you could just store a list of all instances in each class. Conceptually. Not? :-)
Show threadTobiasSep 22, 2023
@LinqLover @squeaksmalltalk @st80 I don't understand how these vars and those instance relate *in the same way* to the pattern you mentioned besides being some kind of state. I think we should discuss that in a different format :D
Show threadChristoph Thiede Sep 23, 2023
@krono @squeaksmalltalk @st80 The way I meant was that they form an aggregation relationship (as in UML aggregation) ...
Show threadTobiasSep 24, 2023
@LinqLover @squeaksmalltalk @st80 But they're definitively on a different level of abstraction.
Show threadChristoph Thiede Sep 25, 2023
@krono @squeaksmalltalk @st80 Yes ... but they fulfill the same kind of relationship regarding the multiplicity between superclass objects and the state of (sub)class objects in this argument, I think ...
Show threadTobiasSep 25, 2023
@LinqLover @squeaksmalltalk @st80 In that case there is no difference between a method and a collection, right?
(im kidding)
The meta/non-meta-relationships between classes and variables on the one, and instances on the other hand it extremly important.
It makes no sense to me to throw them in the same pot just because they form a 1:n-relationship in a diagram.
It's a feat of Smalltalk that you can express these the same way, but that does not mean one has to just because :)
Show threadChristoph Thiede Sep 26, 2023
@krono @squeaksmalltalk @st80 Alright, then I'm giving up. ;-) I will stick with "no super on class side" as a necessary oddity of Smalltalk's metaclass design. Maybe this stuff would be more fun with prototypal programming systems (I haven't tried that yet (but building a SelfObject in Squeak was a nice little exercise, just needs proper tool support :D)) ...
Show threadTobiasSep 27, 2023
@LinqLover @squeaksmalltalk @st80 Maybe it's also just a corrolary of the "where is the strange loop" question of meta-capable programming systems (eg, Smalltalk, Python, Ruby, etc.pp.)
Show threadChristoph Thiede Sep 29, 2023
@krono Likely! But class-free systems would not have such a strange loop (just a null pointer to a prototype), right? I see that the header in your screenshot reads "Self" but I cannot find the document online :D
Show threadTobiasSep 30, 2023
@LinqLover I send it to you.