I built for our research a model for exchanging source code model 
(granularity been not AST)

in this model we could have in a stupid syntax


(Class
	(name Morph)
	(belongsTo Namespace1)
	(containedIn Package2)
	)

"in our case inheritance in explicitly modelled not really good for 
squeak"
So I would change it as

(Class
	(name 			#Morph)
	(superclass 	#Object)
	(type 			#named)
	(belongsTo 		Namespace1)
	(containedIn 	Package2)
	)

(Class
	(name			#Array)
	(superclass		#ArrayedCollection)
	(type			#indexed)
	(	.....
	)

(InstanceVariable
	(name bounds)
	(belongsTo Morph)
	)

(Method
	(name fullBounds)
	(belongsTo Morph)
	(code 	"fullBounds
				^ bounds")
	)

Each entity could be then annotated
	with:
		author
		date
		category
		version
		

We were transferring other information but not important for smalltalk.
I guess that designing such model could go really fast.

This was the idea behind Ginsu.
We could have then

An extension but not based on convention a simple supports for package.

(Method
	(name myFunkyFullBounds)
	(belongsTo Morph)
	(containedIn MyMorphWonderfullPackage)
	(code 	"myFunkyFullBounds
				^ bounds")
	)

I do not see why this model would not work for versioning.


On Monday, April 7, 2003, at 09:00 AM, Avi Bryant wrote:

>
> On Mon, 7 Apr 2003, Stephane Ducasse wrote:
>
>> Hi avi
>>
>> I still strongly believe that having a declarative model would be
>> excellent.
>> Do you think we could built something on top of moticello?
>
> Monticello's model is geared very specifically towards versioning.  
> One of
> the results of this bias is that each code element is modelled largely
> independently.

This is a key point. We do not want XML-tree, you want to have a flat 
model


> A single Revision may contain both the declaration of a
> method and the definition of the class that method belongs to, but 
> there
> is no explicit link between the two (no object references from one to 
> the
> other) - only a correspondence of names.

In our model the only reference are the ones I show you. A class is for 
VW code
defined in a namespace, a method in a class but it contained in a 
package

This way we could have

(GlobalVariable
	(name 	Transcript)
	(initialized	"TextCollector new")
	)

(PoolVariable
	(...
	)


>  It is only when the code is
> being loaded from the model into the image that those two will be 
> linked
> up.  This makes for much simpler diffing, patching, and merging
> operations, and allows things like class extensions to be modelled with
> minimal fuss, but I have no idea if it would be an appropiate base for
> what you're trying to build.  Can you give me some idea of what that 
> might
> be?

I think that this is pretty the same. So I would not mind allocate some 
time on that.

Stef





Prof. Dr. Stéphane DUCASSE
http://www.iam.unibe.ch/~ducasse/
  "if you knew today was your last day on earth, what would you do 
different? ...  especially if,
  by doing something different, today might not be your last day on 
earth" Calvin&Hobbes

"The best way to predict the future is to invent it..." Alan Kay.

Open Source Smalltalks: http://www.squeak.org, 
http://www.gnu.org/software/smalltalk/smalltalk.html
Free books for Universities at 
http://www.esug.org/sponsoring/promotionProgram.html
Free Online Book at 
http://www.iam.unibe.ch/~ducasse/WebPages/FreeBooks.html