This page is no longer maintained — Please continue to the home page at www.scala-lang.org

Re: Scala pre-SIP for your consideration

No replies
Andrew Forrest
Joined: 2008-12-20,
User offline. Last seen 42 years 45 weeks ago.
Yeah, I did actually consider this (ditching "AnyRef.finalize") in one of my early drafts.
However, I went back and left 'finalize' in, because:
 * Scala code can declare 'native' methods -> native methods probably want to allocate native resources -> 'finalize' seems to be the standard JVM way to deallocate native resources. (Implementing WeakReferences add a bunch of boilerplate code.) * I was already changing big things, and didn't want to create even more of an uphill battle for myself :) * The 'finalize' problem seemed much smaller than the 'constructor' problem anyway.
Having said that, I'd be surprised if there was much (any?) existing Scala code which actually /uses/ finalize (which could be used to argue it both ways :). If 'finalize' disappeared I don't think many would mourn for it. And it would remove another chunk of complexity from my proposal.
Does anyone have any experience in this area (object finalization/cleaning up native resources)?
--Andrew

On 4 Jan 2009, at 00:15, John Nilsson wrote:
Regardig finalizers, as long as we are talkig about finalizers defined in scala maybe it would be better to just dissallow them entierly.
Finalizers aren't guranteed to run anyway so they are not a safe way to release resources.
Another way to handle resources at garbage collection time is with the use of phantom references. Maybe their use is more sage in light of your SIP too.
BR,John

On Sat, Jan 3, 2009 at 8:34 PM, Andrew Forrest <andrew [at] dysphoria [dot] net> wrote:
Hi,
I'd been thinking through how an implementation of Scala might work with 'null' removed… having been attracted by non-nullability in Nice and other languages (the pure functional languages, and Spec# and F#).
My main idea was that null in Java should equate to None in Scala. The largest difficulties are in ensuring that object constructors cannot leave any null references lying about, and deciding what to do about newly-allocated arrays of references. I think I have a solution to these, and I've written it up as a pre-SIP, here:
http://dysphoria.net/scala/sip-nulls.xhtml

Be interested to hear what you think. Undoubtedly there are areas which could be clearer, and undoubtedly there are some corner cases which I haven't considered.
If you're interested, I blogged about a previous version of this idea here: http://dysphoria.net/2008/11/22/removing-nulls-from-scala-some-thoughts/  It's less thought-through, (and in particular has a more awkward approach to arrays), but it is written more chattily, and possibly better explains my line of thought.
Best regards,

--Andrew Forrest



Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland