A small (and objective) taste of Objective-Smalltalk
blog.metaobject.com
blog.metaobject.com
I also like the interesting direction you went with pattern matching selectors. That is a nice change and quite different from your typical Smalltalk or Objc code.
The pattern matching is for Polymorphic Identifiers[1][2], which in turn support what I call "in-process REST"[3][4].
[2] https://www.hpi.uni-potsdam.de/hirschfeld/publications/media...
[3] https://www.slideshare.net/MarcelWeiher/in-processrest
[4] https://rd.springer.com/chapter/10.1007%2F978-1-4614-9299-3_...
The problem with something like KVC is that you then have to lift everything into this new "KVC language", which is embedded as strings in the main programming language.
Which then gets you to dictionary-oriented programming (Xcode, I'm looking at you) and that's really quite painful. While doing performance work at Apple, I though about forming an association called DUKE, Developers United against Keyed Everything :-)
On the other hand, there obviously is a lot of benefit to KVC and KVC-like mechanisms, because we keep re-inventing them everywhere and all the time. I myself had done so with the BBC project that led me to in-process REST. And at one point it just clicked: language support for URIs, and URIs really are universal, so we don't need any other identifiers.
Scheme handlers (or stores[1]) were initially implemented that way. There is a protocol of methods taking references, and you implement these methods, for example -objectForReference:, with, as you write, runtime parsing of the reference (often, but not necessarily strings).
Having implemented a good number of stores[2] and scheme handlers[3] that way, I can tell you it gets old quick. :-)
Given the emphasis I put on Polymorphic Identifiers in Objective-Smalltalk, it was obvious that I needed better language support for scheme-handlers, generalising the "properties" concept found in many languages now (Objective-C, C#, Swift, Python) with path- and pattern-matching as found in various REST toolkits was one of those in-the-shower epiphanies.
The patterns ( /:table/count ) mean that you don't actually have to have a separate endpoint for each path, you can group semantically related paths as you wish. There is also a wildcard pattern (the asterisk) if you want to just match everything beyond that. So for example:
/property/* { |= { 3.} }
/property/*:path { |= { path. } }}
[1] https://github.com/mpw/MPWFoundation/blob/master/Documentati...
[2] https://github.com/mpw/MPWFoundation/tree/master/Stores.subp...
[3] https://github.com/mpw/Objective-Smalltalk/tree/master/Schem...
It's just "Objective-C without the C". Except for real.
Mostly just leave out the square brackets and enjoy the unified syntax.
> perspective of an Objective-C developer
That's my perspective :-) Have been programming in Objective-C for well over 30 years now.
I actually started pre-NeXT with my own pre-processor and runtime, had a C compiler and read a lot about OO and really wanted to program that way. Objective-C seemed achievable, and it was.