Boo

No comment means no strong opinion against this?

I agree that fields should be private by default, and that 0.9 is a good time to change that. I suspect Bamboo would feel otherwise, though.

Oh I do not suggest changing them 'private' (though that would be my preferred choice too, hence BOO-1091 ).
'internal' would actually be even more permissive than 'protected' within the same assembly.

But I think this is a good tradeoff since it :

• does not break anything, changing to private would obviously break a lot of code (and would make prototyping/subclassing 'harder')
• allows quick prototyping (within the same assembly), sounds boo-ish to me.
• does not, as currently, create 'by default' an unwanted/unnoticed/undesirable visible API usable by external code (this the main problem of current default imho)
• helps 'by default' avoiding bad coupling between assemblies, and makes boo-generated assemblies less noisy on static analysis tools.

So, should we take the opportunity of 0.9 to make the change?

I think 'internal' is worse than 'protected'.

Well 'worse' is relative depending you dislike/fear more internal bad coupling than external/third-party bad coupling, but I get your objection.

Any chance we could then be more 'disruptive' and directly changing to 'private' ?
As Avish suspected I'm not holding my breath about it ( ) and am not sure it's worth the 'breakage', but well, since now is a good time if we ever decide to do this, it's the moment to ask.

Although there is BOO-1091 to workaround this when one prefer other defaults, maybe we could add a "--strict" compiler option that is more conservative on this kind of things (I think we discussed some time ago about such a potential "strict" mode for other things as well [1]).
What do you think?

1:

• minimum visibility by default (like C#)
• API-related types must be explicitely declared (method parameters + return types) [suggested by Daniel and Oren/Ayende on the list, and I like it too (especially for visible methods, I do this all the time it makes code more solid and easier to read/grep imo, so having the compiler to enforce this in strict mode sounds good to me)]
• more?

The main issue I see right now is that such a change could silently change behavior. The following compiles without errors no matter if the 'i' field is protected or private:

class Base:
	i = 0
	
	virtual def foo():
		print i
	
class E(Base):
	def foo():
		i = 42
		print i

And the programs are not equivalent.

That should give an error if 'i' is private.

Hmm yeah so we cannot change it ever now
Well interestingly I just thought about another alternative (that made me discover BOO-1114) : "protected internal"
(which would not change behavior in your example above, but sadly would for external assemblies using a default protected field - I'm not sure it is very common out there but it's still silent breakage)

Are you ok with the --strict compiler option? Any idea for another default that could be more conservative?

In my opinion, a "--strict" option should not allow implicit variable declarations. We'd need some keyword to explicitly declare a variable without having to specify its type. Like "Option Explicit On" in VB.
I realize this is a large change to Boo, but it's not a good idea to silently change field assignments to variable declarations just because someone changed the base class.
So private could be the default in strict mode, and Rodrigo's 'i = 42' example would be a compiler error.

And also something like "Option Strict On" in VB is necessary: disable implicit downcasts.
Currently it's possible to call a method with the signature 'def Method(a as object, b as string)' with 'Method(aString, anObject)' and you get no compilation error/warning, only an InvalidCastException at runtime.

>We'd need some keyword to explicitly declare a variable without having to specify its type.
>I realize this is a large change to Boo, but it's not a good idea to silently change field assignments to variable declarations just because someone changed the base class.

A way to do this change without too much work, and more importantly without introducing a new keyword (which would make --strict mode quite impractical imo) would be to enforce naming of fields with _ prefix like recommended in Boo documentation, and disallow _ prefix for variables.
This way in strict mode this kind of behavior change because of base class change would not be able to happen
And this would work as-is for existing code which has been following the style recommandation (quite a lot actually if I'm not mistaken)

Won't fix since it is too breaking.
Can do it through Strict Mode (BOO-1115) or pragma (BOO-1125).