- 33comments
- 141comments
- 296comments
- 31comments
- 499comments
- 103comments
- 88comments
- 139comments
- 12comments
- 294comments
- 3comments
- 352comments
- 20comments
- 1comments
- 20comments
- 85comments
- 45comments
- 102comments
- 42comments
- 5comments
- 6comments
- 113comments
- 273comments
- 6comments
- 3comments
- 89comments
- 76comments
- 2comments
- 94comments
- 16comments
An interesting project. And the first that I know of that integrates something like Smalltalk directly into a Unix environment.
there's gnu smalltalk: http://smalltalk.gnu.org/
I like the syntax.
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.
Thanks!
The pattern matching is for Polymorphic Identifiers[1][2], which in turn support what I call "in-process REST"[3][4].
[1] http://objective.st/URIs/
[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_...
I briefly thought about the beginnings of this after looking at KVC. I pondered the dots vs slashes question, what a query would look like, and whether every object in a process could have a name. Fun to think about, but that is as far as I got. You have taken this much further.
:-)
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.
Huh, this is an interesting solution. When I started reading this post and took a look at the syntax, I had expected some sort of sugar that looked like Swift's @dynamicCallable where the "selector" would be passed in as a string and you'd parse it at runtime. This way, you don't have a specify an "endpoint" for every operation, but I guess you lose some compile-time checking?
Thanks!
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:
Returns the number "3" for all paths prefixed by "/property".
Returns the remainder of the path (or you can use it for your own custom matching).
[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...
Interesting, I will have to try it out myself when I get some free time. While I don't know Smalltalk very well, from the perspective of an Objective-C developer the way you have designed the project's features is quite fascinating.
It's just "Objective-C without the C". Except for real.
Mostly just leave out the square brackets and enjoy the unified syntax.
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.