Today we were discussing about that with Camille. Actually we would like to split the current compile into: - compile: just compiles and returns the compiled method. The method is not installed in the class. Nobody knows it's there. - install: it properly installs the method in the class, and notifies whoever needs installs it. Compiling is always silent by default, as it has not really an effect in the system. Then, the silentliness should be in the install part. Even, logging the source code in whatever source code representation we want (now the changes file) should be part of the installation (and pluggable). El jue., 28 de may. de 2015 a la(s) 4:55 p. m., Thierry Goubier < thierry.goubier@gmail.com> escribió:
2015-05-28 16:49 GMT+02:00 Nicolai Hess <nicolaihess@web.de>:
How silent should "compileSilently" be?
no trace in the system : 15314 <https://pharo.fogbugz.com/default.asp?15314> compileSilently and method history / changes file
not half silenlty 13023 <https://pharo.fogbugz.com/default.asp?13023> Test Cases should not do things half silently
not "SystemAnnouncer-silent" 10560 <https://pharo.fogbugz.com/default.asp?10560> SystemAnnouncer and compileSilently
?
What do you think, what granularity of "silent" do we need. I see at least three different use cases:
- just an ordinary compile
? Silent means that: Core infrastructure is not updated properly (i.e. RPackage) and tools (Browsers) can end desynchronised with the methods.
- compile for tests
Probably the one... But I wonder if this is a good idea anyway. I'd believe most tests using silently are using it wrongly and shouldn't be using it in the first place.
- compile autogenerated methods.
This one may not be silent. If the auto-generated method will be visible (saved in a package, can be browsed, etc...) then it shouldn't be silent.
Thierry
nicolai