Re: Where to use SELF - your opinion

[Randall.Smith@Eng.Sun.COM (Randy Smith)]

> 
> I would summarize your message as follows:
> 
> C/C++:
> 	costs:	writing type declarations
> 		finding memory management bugs
> 
> 	benefits:
> 		type errors caught at compile time
> 		consistently fast execution
> 		better documentation of programmer's intentions
> 
> Self:
> 	costs:	much larger run-time memory requirements
> 		much less predictable execution time
> 
> 	benefits:
> 		faster turnaround for source changes
> 		no memory management errors
> 
> (The fast turnaround problem is being addressed by the C++ vendors, as I'm
> sure you noticed at OOPSLA.)
> 
> Reading this balance sheet, I would conclude that C/C++ are good for some
> things, and Self is good for other things.  For production code, I think
> C/C++ have clear advantages, especially since (as I *didn't* note above)
> there is no commercial-style Self implementation (with documentation,
> support, portability, etc.)
> 
> 				Peter
> 

I'd sort of agree, except here are some thoughts on the "type errors
caught" and "better documentation of programmer's intentions" items.

We could use the concreteness of Self to advantage.  When compiling a
method, all messages sent to self can be "type checked" as to wheather
or not they will be understood.  Also, the programmer can set values
for temporary slots in a method at compile time - we do this as an
informal programming practice today to represent illustrative values
for temporaries. (We could imagine doing this for arguments as well.)

This could be supported by the environment in an optional kind of
way..."Warning: This method sends '<' to 'temp3' which currently
contains a matrix.  A matrix does not understand '<'. Click on 'abort,'
or click on 'ok' to continue."

The value of this is diluted slightly by dynamic inheritance, and the
fact that Self is, after all, untyped...slots can hold anything anyway,
and on occasion certainly will hold things very different than the
compile-time value.

As a motivational story: I thought the Smalltalk browser was improved
somewhat when the support for "concrete class variables" was added: you
could select a class variable in a method's text, say "inspect" .. and
lo and behold, there was the actual class variable object in the
flesh!

I'm proposing that Self is in a position to do this for any
send-to-self name that appears in a method, plus use the information
to provide hints to the programmer when compiling.

When it comes to intention declaration, this scheme could compete
favorably with C's static type declaration scheme, which is kind of a
bummer anyway (not optional, and can prevent reuse by its narrow view
of type.)