On Wed, 9 Dec 1998, Adam P. Jenkins wrote:
>
> Also, is there some deep Smalltalk principle here that is the explanation
> for this policy of sharing literals in a method, or is it just to save
> memory?

I'd like to hear more about this as well.  It seems to me that having
duplicate strings/constant arrays in a method would be a rare enough
occurence that you wouldn't really save that much memory anyway.  (Out of
the blue, I'd guess 1-3% of them would be duplicates...?)  The only
potentially common case I can think of is when you're initializing several
strings (or arrays) to be empty, but "initializing" implies that you'd
want to be able to modify them independently at some point in the future. 

> Every other high-level language that I've used -- TCL, Java (is java
> high-level?)

How about medium-level? :-) 

> Perl, Python, Basic, O'Caml, ML, Prolog, Lisp, Matlab --
> all create a new object in response to a string or array literal. 
> (Actually ML and Python use immutable strings, so this whole problem
> isn't an issue for those two, at least for strings.) Note that these
> languages are free to not actually create a new object each time; they
> could use a copy-on-write scheme to avoid unnecessary copying yet still
> give the semantics of unique objects.

This sounds like a much better solution to me than making literals
read-only.  I don't know all of the issues behind implementing a
copy-on-write scheme in Smalltalk, though... would there be a big
performance hit? 
 
- Doug Way
  dway at mat.net
  dway at transom.com
  http://www.transom.com