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 :
compileSilently and method history / changes file

not half silenlty
Test Cases should not do things half silently

not "SystemAnnouncer-silent"
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