On Monday, January 20, 2003, at 03:44 PM, Tyler Close wrote:

> On Monday 20 January 2003 15:44, Robert Withers wrote:
>> In rereading what  you originally wrote, what gave me
>> pause was your stance on the less dynamic view that the other side
>> would have to be independently upgraded to support the new types.
>> There is no reason we couldn't dynamically build a meta-representation
>> of the type, as well as start attaching facets to that type so it 
>> could
>> operate in a service environment.
>
> Facets are behaviour. How are you going to attach behaviour to an
> unknown type without defining a universal runtime? Are you
> planning to implement a Kernel-E interpreter?


Tyler, a common misunderstanding is what it means that squeakers 
develop inside their runtime.  I don't know if you're a lisper or 
Smalltalker or not.  If a new class just showed up in front of me, I 
could start adding methods to it.  There are several implementations of 
grouping subsets of behavior into Traits or facets.  I believe they can 
be attached to any Behavior instance.

We  have  a universal runtime over here in Squeak.  :)    Aside from 
all the bit-identical platforms (21?), we have access to all the source 
code of the vm, in fact, I changed the method lookup primitive to 
support Refs.  vm: (http://minnow.cc.gatech.edu/squeak/1447).   vm 
maker (http://minnow.cc.gatech.edu/squeak/2105).  virtual machine 
hacking (http://minnow.cc.gatech.edu/squeak/407).

I wasn't going to implement a E interpreter (who will do this, I 
wonder?).  I mean adding new MirandaMethods, as I understand them now, 
or override existing ones.   Well, not MirandaMethods, because they 
don't have to be understood by everyone.   If you send me an object of 
unknown type, I could attach some behavior to it's new Class instance, 
and then you could eventual send those messages to that object, without 
getting smashed.


>
>> CDR back-of-the-envelope analysis:
>>> 1. it should be a binary representation for performance and 
>>> scalability
>>> reasons
>>
>> yep
>
> Any stats?

no.  I think your parser is very fast.

>>> 4. it should be easy to register mappings for new types
>>
>> IDL.  interfaces can be published.  a new incoming types can be looked
>> up in an interface repository.  this has nothing to do with encoding,
>> but rather implementation resolution of encoding.
>
> How do you create a collision-free namespace for new types?


use a RuntimeEnvironment to localize them to that process.  I like 
embedding the type resolver in the connection.

The only reason I push back is that there may be other forms of 
communication we could do between 2 squeaks, like passing blocks and 
debugging remote stacks.  it would great if some of that could be built 
between E and Squeak, but that will probably have to follow the typing 
model of squeak.   Dynamic typing is the only way that 2 different 
environments will be able to migrate code between them.

cheers,
robert