Hi!

nicolas cellier wrote:
> We don't even have to use classes names like MethodChange:
> Predefine a file scope variable theBuilder := DeltaStreamBuilder new.
> 
> theBuilder license: 'MIT'.
> theBuilder addMethodFor: 'MyClass' sourceCode: etc...
> 
> We have replaced class names with an API.
> As a result, theBuilder can be set to another class just enumerating non-MIT
> licence or whatever task you want it to.
> 
> Isn't that simple enough?
> Is there a good reason to restrict our power?

I agree that this is a tempting route, for example, SM used something 
like this in its first incremental update protocol. My personal reasons 
against it are:

- Safety. When we expose "full Smalltalk" in the file format you can do 
naughty stuff in it, both for malicious intent OR more likely "smart 
things" that will cause unwanted effects.

- Speed. I think it will be much slower. Slow to be a problem? Not sure, 
but I want to gobble tons of Deltas so the more speed the better.

- Compiler limitations. There are a fair deal of Compiler limitations to 
deal with regarding number of literals, yadda yadda. A problem? Not sure.


...BUT... :)

On the other hand, a handwritten parser that can "parse a sequence of 
Smalltalk messages to self using Strings, Integers, true, false, nil and 
Symbols with comments in it" might be more than enough and would avoid 
ALL THREE of the problems above. Example:

"This is a cool delta!"
protocol: #delta1.  "<- tell builder which protocol we use"
delta: 'MyDelta' author: 'Göran Krampe'. "<- start a delta"

"Here comes a single method source change in a single message"

methodSourceChange: #SomeClass
protocol: #some-method-category
stamp: 'elder 3/21/1996 12:34'
source:
'add: a to: b
"Method comment"

| result |
^result := a + b'.


...so while not exactly Smalltalk code that can be fed to the regular 
Compiler it would still be parsed and executed like a series of 
#perform: to a builder object. It would be fast (modulo speed of 
#perform:), secure (you can't run arbitrary code) and avoids limits of 
Compiler.

...ok, but what are the advantages compared to JSON?
I presume these at least:

- Easy to plug a different builder, like you mention.
- Syntax is familiar to Smalltalkers. And Smalltalkers grok the builder 
object "fed by messages" idea.
- Same escaping logic for Strings like in Smalltalk.
- A builder could easily implement DNU to handle/ignore messages it does 
not understand/want to deal with
- Lends itself more naturally to a "streaming" implementation like SAX.

I can't see any real disadvantages compared to JSON/YAML.

Cool! :) Comments?

regards, Göran