Monticello status

Avi Bryant avi at
Tue Apr 8 20:24:25 UTC 2003

On Tue, 8 Apr 2003, Stephane Ducasse wrote:

> >
> > No, that's different.  It's perfectly legal (and the behavior is very
> > well
> > defined) to have a method sending a selector that does not exist (or
> > referencing a global that's not declared, for that matter).  Using a
> > missing instance variable seems to cause undefined behavior, however.
> > It certainly doesn't throw any nice exception like MNU.  So I'd really
> > like to catch that at load time.
> ummm I do not really agree because you could change the compiler to
> raise a
> VariableNotIdentified and you get exactly the behavior you want. You
> compile the method and if there is an error you roll-back.

Well, ok, if we're allowing rollbacks that makes things easier.  But I
would like to avoid implementing a rollback mechanism if at all possible.

And there's still a difference between a missing method (which is a
runtime error) and a missing instance variable (which is a compile time
error).  Runtime errors are not something we can or should catch with
static analysis, pretty much by definition.

> I did it for our meta-model with a good visitor you can extract that
> easily, the problem is not there this is that at the end you end up
> with a lot of accesses in your file for not too much gain.

> Yes but look at the author names, there are attached to the changeset
> now and not with the entities. We can see that as an optimization :)

Good point - the live entities are already linked to a particular dead
entity, the .changes file.  I remember Andreas saying something about
being able to modify that mechanism to point to something else, I think -
maybe it could be used to store a reference to the Declaration object...

> Any way we agree. I can review your code if you want (I promised myself
> to only look at rosetta/ ginsu old version to let my mind elaborate but
> I have some hard dead-line so no fun coding)

Feel free to review it.  There are a number of places I know need to be
improved, and just haven't had time to improve it - but I'm happy to have
you confirm they need to be improved as well ;).

More information about the Squeak-dev mailing list