>
> 1.  Ian has a beautiful new architecture for J5 that hasn't even been
> optimized yet (of course I haven't seen the latest ;-).  I want to
> see how it does before tampering with the language.
>
> 2.  Some people are experimenting with mix-ins and with alternatives
> to mix-ins to factor the kernel (and anything else) more cleanly.  I
> want to see where these experiments lead.  It is great to have
> StrongTalk as a basis for comparison in simplicity and power.
>
> 3.  Regarding a type system for Squeak, I would really like to see
> this done in a non-invasive manner.  That is, there would be a type
> system and type inference mechanism, it would not even be seen by the
> casual programmer, it could be turned on at any time, and stable
> releases would be "clean" with regard to the types, and any
> associated documentation could leverage off that information.
>

Dan,

	Since we've all pretty much agreed in the past that what matters in ST 
is the protocol spoken, not the actual class/type of the object itself, 
then why not do 'typing' using protocols?

	Problem is organizing protocols in Squeak...

	Solution? Traits!

	Using Traits, we organize messages into traits. The typing then 
involves 'what other objects can speak/understand' this protocol.

	My gut instinct says this helps simplify typing tremendously. 

	If message 'b:' on object instance of class 'C' takes a object instance 
of Class 'D'.
	
	instanceOfC b: instanceOfD

	And message b: internally sends a message e to D
		
	b: inputObj
		^ inputObj e. 

	Then, if message 'e' on object instance of class 'D'  is part of Trait 
'X'.

	And Trait X is implemented and used by instances of classes 'Q', 'R', 
'S'

	Then can't we automatically determine that the TYPES supported by b: 
are D, Q, R, S?

	Once we breakdown and build up the traits, we get type inferencing for 
free? Or at least, we get a lot of the type hinting for free. I really 
don't like Strongtalk's type hinting syntax...

	Or am I smoking something?

	-Daniel