
A small (and objective) taste of Objective-Smalltalk - mpweiher
https://blog.metaobject.com/2019/02/a-small-and-objective-taste-of.html
======
drudru11
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.

~~~
mpweiher
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/](http://objective.st/URIs/)

[2] [https://www.hpi.uni-
potsdam.de/hirschfeld/publications/media...](https://www.hpi.uni-
potsdam.de/hirschfeld/publications/media/WeiherHirschfeld_2013_PolymorphicIdentifiersUniformResourceAccessInObjectiveSmalltalk_AcmDL.pdf)

[3] [https://www.slideshare.net/MarcelWeiher/in-
processrest](https://www.slideshare.net/MarcelWeiher/in-processrest)

[4]
[https://rd.springer.com/chapter/10.1007%2F978-1-4614-9299-3_...](https://rd.springer.com/chapter/10.1007%2F978-1-4614-9299-3_11)

~~~
drudru11
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.

~~~
mpweiher
:-)

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.

------
saagarjha
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?

~~~
mpweiher
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:

    
    
       /property/* { |= { 3.} }
    

Returns the number "3" for all paths prefixed by "/property".

    
    
       /property/*:path { |= {  path. }  }}
    

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...](https://github.com/mpw/MPWFoundation/blob/master/Documentation/Stores.md)

[2]
[https://github.com/mpw/MPWFoundation/tree/master/Stores.subp...](https://github.com/mpw/MPWFoundation/tree/master/Stores.subproj)

[3] [https://github.com/mpw/Objective-
Smalltalk/tree/master/Schem...](https://github.com/mpw/Objective-
Smalltalk/tree/master/Schemes)

~~~
saagarjha
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.

~~~
mpweiher
> don't know Smalltalk very well

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.

------
tempodox
An interesting project. And the first that I know of that integrates something
like Smalltalk directly into a Unix environment.

~~~
zem
there's gnu smalltalk: [http://smalltalk.gnu.org/](http://smalltalk.gnu.org/)

