Indeed, I like this approach. Nicely done. Doru On Tue, Oct 7, 2014 at 9:11 PM, stepharo <stepharo@free.fr> wrote:

This sounds like a good strategy this difference between interactive and loading time.

On 7/10/14 18:25, Marcus Denker wrote:

...

Hi,

In Pharo3 we had the bug that assigning to method arguments was allowed.

*Block* arguments are traditionally assignable, but this is equally a bad idea (there was already a setting to forbid it, but no idea how to make it a default without making a lot of code unlovable).

First we made method arg assignment in Pharo4 an error, like it was in Pharo2, but the problem with that is that there is code out there already… so (thanks to Nicolai Hess), now assignments to method arguments raise an error in interactive mode (when coding), but load fine e.g. with Monticello.

Yesterday I extended that scheme to block arguments: Now block argument assignments are forbidden in interactive mode, while legacy code loads fine.

(I removed the #allowBlockArgumentAssignment setting, too).

This way we have a good transition and in some versions can make raising errors on assignments to arguments the default even in non-interactive mode.

Marcus

-- www.tudorgirba.com "Every thing has its own flow"

On 07 Oct 2014, at 21:42, Esteban A. Maringolo <emaringolo@gmail.com> wrote:

If I evaluate: (CodeImporter evaluateFileNamed: 'foo.st')

In a headless pharo image, does it count as interactive?

Normally not… it should be non-interactive in all cases. (like loading monticello, loading change sets…) Marcus