[squeak-dev] [Election] ...is soon upon us! Last day info

keith keith_hodges at yahoo.co.uk
Fri Mar 12 22:51:15 UTC 2010


> You're simply wrong on this.  I, with help from others, managed to  
> get the closure compiler into several dialects quite recently and I  
> can assure you that changing the compiler under one's feet is  
> tricky.  There is nothing inherent in the trunk model that hinders  
> difficult change.

When the change is finished.

You made the changes off-line using your own processes. Therefore the  
development "process" is not trunk, it is whatever you used at home  
because trunk wasn't appropriate for the task. Trunk is only the  
publication mechanism, and I will bet the trunk process didn't help  
you by making the development process easier in any way.

>  A coordinated series of package updates is just as powerful as  
> changesets.

How do you go backwards, if you are always going forwards?

> One simply has to try and try again

where? I don't have any control to un-commit stuff from trunk.

> because one will make mistakes and the system will break and one  
> will be able to discover why and compensate.  Don't confuse the  
> medium with the message. Change sets

Are simple flexible and powerful, and file in can be implemented in  
one class.

> and MC packages are

are very rigid and complex and require a specific version of MC, which  
happens not to be the version I use.

> media but they can convey many messages.  Eventually one gets to a  
> depth at which these media fail to do the whole job (for example  
> changing the object format, bytecode set etc).  But Smalltalk's  
> reflective nature is what makes both of these media equally powerful  
> and equally unsafe.  If you want to make deep changes you simply  
> have to be prepared to fail, to be confused, to be persistent

Sure, you can do that in your own process at home. but you cant do it  
with trunk. Being confused, and failing is my default state. So  
therefore trunk is of no use to me.

Keith





More information about the Squeak-dev mailing list