On 14 févr. 04, at 10:39, Avi Bryant wrote:

>
> On Feb 14, 2004, at 12:20 AM, ducasse wrote:
>
>> Yes this is another possibility. we can always as a large table with 
>> data/annotations on other entities.
>> But this means that tools will have to be adapted anyway. So at the 
>> end I think the cleanest way is to have other entities.
>
> Those aren't the only two options.  There's no reason the Class object 
> couldn't itself have more sophisticated information about itself, eg, 
> actual objects for each inst var instead of just a list of names (is 
> there?).  That's the kind of thing I'm thinking of.

Ah. yes you could have that but people worrying about small footprint 
may not like it. This is why digitalk guys had this
separation. At that time 93 they were able to produce image of 10k with 
hello world. (I guess they also removed some reflective part).

>
>> The idea with Ginsu is that you could have different version of the 
>> same class loaded in parallel and other. I think that joseph would be 
>> better to answer this question that I the morning.
>
>> This is also a way to have a clear separation between run-time 
>> entities and declarations. This way you can code in Squeak code for 
>> Squat or another Smalltalk.
>
> It comes down to whether you want to be editing live objects or "dead" 
> representations of them - that is, are your tools operating on the 
> same instances that the VM is or not?  I'm biased towards the former, 
> though I can certainly see the advantages to the latter.  But I think 
> those advantages are better achieved by working on things like 
> mirrors... that is, I don't want to introduce an indirection that is 
> only used by part of the system (like the Browser), but if the 
> indirection were consistently used throughout we might gain by it.

I agree. I always have this dilemna:
	on one hand this is powerful to manipulate direclty living objects
	on the other hand this is good to have tools with a real declarative 
syntax

My current impression is that when you are coding manipulation 
declaration is really not a problem, as soon
as you install run-time objects. Then if you need you can remove the 
declaration. So there are certainly a duplication of functionality
or at least delegation (if we image that I can compile a method from a 
run-time entities and from a declaration entities that would possibly 
forward that to the run-time entities.

> It's likely too late for me to be making any sense, so I'll stop 
> there. :)

:)

>
>> This was what they did at Digitalk and I think that they were right. 
>> At least they had the manpower to think and do it.
>
> Just because they thought about it doesn't mean we shouldn't too... ;)
Yes.
Once I discusses with allen because I like nearly all the parts of the 
story and I asked hom how he would reintroduce
reflection in the modular smalltalk he presented in the OOPSLA 89 
paper. He replied tower of interpreter but the right answer is
clear api and mirrors. :)


So to summarize I think that having a good code model would be good and 
this would remove a lot of small
problems and ad-hoc fixes to support monticello. If one day (I do not 
really believe) joseph release the new version
of Ginsu I will port it to Squeak if necessary, or least we will be to 
have a look.

Now my intuition tells me that there will be more demands for 
monticello support and the more people ask the more freedom you will 
have to do it right :) so the future is bright.


>
>