On 28 May 2015, at 18:34, Guillermo Polito <guillermopolito@gmail.com> wrote:

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).

That���s a great idea!
Just one request: please keep a single selector to do compilation + installation (what #compile: currently does). That���s very convenient and it���s the bevhaviour you (I) usually want.

Cheers,
Max




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