Boo

Strict mode

Details

  • Type: New Feature New Feature
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 0.8.2
  • Fix Version/s: 0.9
  • Component/s: Compiler
  • Labels:
    None
  • Number of attachments :
    0

Description

Sometimes Boo is not conservative enough on certain defaults (which still makes sense for other/prototyping usages) that can lead to some errors slipping to a release unnoticed in (large) projects.

Strict mode introduces more conservative(safer) defaults and warnings.
Strict mode is disabled by default.

This compiler option is settable through:

  • "-strict" with booc
  • programatically by setting CompilerParameters.Strict to true
  • "strict" argument with nant and msbuild tasks

When strict mode is enabled the following changes are enabled:

  • default visibility is private like in C# (change made through BOO-1091)
  • methods parameters types and return type of public methods (API) must be explicitely declared [to avoid unnoticed/unwanted binary-compat breakage] (BOO-1132)
  • warns if a variable has the same name as a private field of one of its super types (BOO-1133).
  • implicit return statement fires a warning (BOO-703)

TODO:

  • implicit downcast fires a warning (BOO-943) — default mode? or strict mode only?

Issue Links

depends upon

New Feature - A new feature of the product, which has yet to be developed. BOO-1091 Possibility to change default visibility settings

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • Resolved - A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.

New Feature - A new feature of the product, which has yet to be developed. BOO-1132 WARNING: Visible method|property does not declare return|argument type explicitely

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • Resolved - A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.

New Feature - A new feature of the product, which has yet to be developed. BOO-1133 WARNING: Variable 'X' has the same name as a field of base type 'T'. Did you mean to use the field ?

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • Resolved - A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.

Improvement - An improvement or enhancement to an existing feature or task. BOO-703 Compiler warning on implicit return statement

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • Resolved - A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.
is related to

Bug - A problem which impairs or prevents the functions of the product. BOO-1087 Compiler should warn when an implicit callable is used in a boolean context

  • Major - Major loss of function.
  • Resolved - A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.

Bug - A problem which impairs or prevents the functions of the product. BOO-692 Built-in value type conversions

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
supercedes

Improvement - An improvement or enhancement to an existing feature or task. BOO-1092 Change default field visibility from protected to private

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • Resolved - A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.

Wish - General wishlist item BOO-943 Implicit downcast in strict mode

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • Resolved - A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.

Activity

Ascending order - Click to sort in descending order
Cedric Vivier made changes -
Field Original Value New Value
Link This issue supercedes BOO-943 [ BOO-943 ]
Cedric Vivier made changes -
Link This issue supercedes BOO-1092 [ BOO-1092 ]
Cedric Vivier made changes -
Link This issue relates to BOO-1091 [ BOO-1091 ]
Cedric Vivier made changes -
Link This issue relates to BOO-1091 [ BOO-1091 ]
Cedric Vivier made changes -
Link This issue depends upon BOO-1091 [ BOO-1091 ]
Cedric Vivier made changes -
Description For a number of Boo users, sometimes Boo is not conservative enough on certain defaults (which makes sense for others) that can make some errors slip through a release unnoticed in (large) projects.

Introducing a strict mode would be a nice new feature to introduce and enforce more conservative(safer) defaults if desired.

Strict mode is disabled by default.
Compiler option would be settable through:
- "-strict+" on booc
- CompilerParameters.Strict as bool
- "strict" argument in nant and msbuild tasks


When strict mode is enabled the following changes are enabled:
- default visibility is private like in C# (change made through BOO-1091)
- methods parameters types and return type must be explicitely declared
- field naming recommendations are enforced (ie. _-prefix on non-visible fields), this enforces consistency and unnoticed conflict/behavior-change with variables which have same name than a field.
- implicit downcast fires a warning (BOO-943)
 Sometimes Boo is not conservative enough on certain defaults (which still makes sense for other/prototyping usages) that can lead to some errors slipping to a release unnoticed in (large) projects.

Introducing a strict mode would be a nice new feature to introduce and enforce more conservative(safer) defaults if desired.

Strict mode is disabled by default.
This compiler option would be settable through:
- "-strict+" on booc
- CompilerParameters.Strict as bool
- "strict" argument in nant and msbuild tasks


When strict mode is enabled the following changes are enabled:
- default visibility is private like in C# (change made through BOO-1091)
- methods parameters types and return type must be explicitely declared
- field naming recommendations are enforced (ie. _-prefix on non-visible fields), this enforces consistency and ensure no unnoticed conflict/behavior-change with variables which have same name than a field.
- implicit downcast fires a warning (BOO-943)
Cedric Vivier made changes -
Link This issue is related to BOO-692 [ BOO-692 ]
Cedric Vivier made changes -
Link This issue depends upon BOO-703 [ BOO-703 ]
Cedric Vivier made changes -
Description Sometimes Boo is not conservative enough on certain defaults (which still makes sense for other/prototyping usages) that can lead to some errors slipping to a release unnoticed in (large) projects.

Introducing a strict mode would be a nice new feature to introduce and enforce more conservative(safer) defaults if desired.

Strict mode is disabled by default.
This compiler option would be settable through:
- "-strict+" on booc
- CompilerParameters.Strict as bool
- "strict" argument in nant and msbuild tasks


When strict mode is enabled the following changes are enabled:
- default visibility is private like in C# (change made through BOO-1091)
- methods parameters types and return type must be explicitely declared
- field naming recommendations are enforced (ie. _-prefix on non-visible fields), this enforces consistency and ensure no unnoticed conflict/behavior-change with variables which have same name than a field.
- implicit downcast fires a warning (BOO-943)
 Sometimes Boo is not conservative enough on certain defaults (which still makes sense for other/prototyping usages) that can lead to some errors slipping to a release unnoticed in (large) projects.

Introducing a strict mode would be a nice new feature to introduce and enforce more conservative(safer) defaults if desired.

Strict mode is disabled by default.
This compiler option would be settable through:
- "-strict+" on booc
- CompilerParameters.Strict as bool
- "strict" argument in nant and msbuild tasks


When strict mode is enabled the following changes are enabled:
- default visibility is private like in C# (change made through BOO-1091)
- methods parameters types and return type must be explicitely declared
- field naming recommendations are enforced (ie. _-prefix on non-visible fields), this enforces consistency and ensure no unnoticed conflict/behavior-change with variables which have same name than a field.
- implicit downcast fires a warning (BOO-943)
- implicit return statement fires a warning (BOO-703)
Cedric Vivier made changes -
Link This issue is related to BOO-1087 [ BOO-1087 ]
Cedric Vivier made changes -
Description Sometimes Boo is not conservative enough on certain defaults (which still makes sense for other/prototyping usages) that can lead to some errors slipping to a release unnoticed in (large) projects.

Introducing a strict mode would be a nice new feature to introduce and enforce more conservative(safer) defaults if desired.

Strict mode is disabled by default.
This compiler option would be settable through:
- "-strict+" on booc
- CompilerParameters.Strict as bool
- "strict" argument in nant and msbuild tasks


When strict mode is enabled the following changes are enabled:
- default visibility is private like in C# (change made through BOO-1091)
- methods parameters types and return type must be explicitely declared
- field naming recommendations are enforced (ie. _-prefix on non-visible fields), this enforces consistency and ensure no unnoticed conflict/behavior-change with variables which have same name than a field.
- implicit downcast fires a warning (BOO-943)
- implicit return statement fires a warning (BOO-703)
 Sometimes Boo is not conservative enough on certain defaults (which still makes sense for other/prototyping usages) that can lead to some errors slipping to a release unnoticed in (large) projects.

Introducing a strict mode would be a nice new feature to introduce and enforce more conservative(safer) defaults if desired.

Strict mode is disabled by default.
This compiler option would be settable through:
- "-strict+" on booc
- CompilerParameters.Strict as bool
- "strict" argument in nant and msbuild tasks

In effect, it adds a StrictModeCheckingStep into the pipeline.


When strict mode is enabled the following changes are enabled:
- default visibility is private like in C# (change made through BOO-1091)
- methods parameters types and return type must be explicitely declared
- field naming recommendations are enforced (ie. _-prefix on non-visible fields), this enforces consistency and ensure no unnoticed conflict/behavior-change with variables which have same name than a field.
- implicit downcast fires a warning (BOO-943)
- implicit return statement fires a warning (BOO-703)
Cedric Vivier made changes -
Status Open [ 1 ] In Progress [ 3 ]
Rodrigo B. de Oliveira made changes -
Fix Version/s 0.9 [ 13816 ]
Fix Version/s 0.9.1 [ 14922 ]
Cedric Vivier made changes -
Description Sometimes Boo is not conservative enough on certain defaults (which still makes sense for other/prototyping usages) that can lead to some errors slipping to a release unnoticed in (large) projects.

Introducing a strict mode would be a nice new feature to introduce and enforce more conservative(safer) defaults if desired.

Strict mode is disabled by default.
This compiler option would be settable through:
- "-strict+" on booc
- CompilerParameters.Strict as bool
- "strict" argument in nant and msbuild tasks

In effect, it adds a StrictModeCheckingStep into the pipeline.


When strict mode is enabled the following changes are enabled:
- default visibility is private like in C# (change made through BOO-1091)
- methods parameters types and return type must be explicitely declared
- field naming recommendations are enforced (ie. _-prefix on non-visible fields), this enforces consistency and ensure no unnoticed conflict/behavior-change with variables which have same name than a field.
- implicit downcast fires a warning (BOO-943)
- implicit return statement fires a warning (BOO-703)
 Sometimes Boo is not conservative enough on certain defaults (which still makes sense for other/prototyping usages) that can lead to some errors slipping to a release unnoticed in (large) projects.

Introducing a strict mode would be a nice new feature to introduce and enforce more conservative(safer) defaults if desired.

Strict mode is disabled by default.
This compiler option would be settable through:
- "-strict+" on booc
- CompilerParameters.Strict as bool
- "strict" argument in nant and msbuild tasks

In effect, it adds a StrictModeCheckingStep into the pipeline.


When strict mode is enabled the following changes are enabled:
- default visibility is private like in C# (change made through BOO-1091)
- methods parameters types and return type of public methods (API) must be explicitely declared [to avoid unnoticed/unwanted binary-compat breakage]
- warns if a variable cannot have the same name as a field of its declaring type (or one of its super types).
- implicit return statement fires a warning (BOO-703)

- implicit downcast fires a warning (BOO-943) --- default mode? or strict mode only?
Cedric Vivier made changes -
Fix Version/s 0.9.1 [ 14922 ]
Fix Version/s 0.9 [ 13816 ]
Cedric Vivier made changes -
Description Sometimes Boo is not conservative enough on certain defaults (which still makes sense for other/prototyping usages) that can lead to some errors slipping to a release unnoticed in (large) projects.

Introducing a strict mode would be a nice new feature to introduce and enforce more conservative(safer) defaults if desired.

Strict mode is disabled by default.
This compiler option would be settable through:
- "-strict+" on booc
- CompilerParameters.Strict as bool
- "strict" argument in nant and msbuild tasks

In effect, it adds a StrictModeCheckingStep into the pipeline.


When strict mode is enabled the following changes are enabled:
- default visibility is private like in C# (change made through BOO-1091)
- methods parameters types and return type of public methods (API) must be explicitely declared [to avoid unnoticed/unwanted binary-compat breakage]
- warns if a variable cannot have the same name as a field of its declaring type (or one of its super types).
- implicit return statement fires a warning (BOO-703)

- implicit downcast fires a warning (BOO-943) --- default mode? or strict mode only?
 Sometimes Boo is not conservative enough on certain defaults (which still makes sense for other/prototyping usages) that can lead to some errors slipping to a release unnoticed in (large) projects.

Strict mode introduces more conservative(safer) defaults and warnings.
Strict mode is disabled by default.

This compiler option is settable through:
- "-strict" with booc
- programatically by setting CompilerParameters.Strict to true
- "strict" argument with nant and msbuild tasks


When strict mode is enabled the following changes are enabled:
- default visibility is private like in C# (change made through BOO-1091)
- methods parameters types and return type of public methods (API) must be explicitely declared [to avoid unnoticed/unwanted binary-compat breakage]
- warns if a variable has the same name as a field of its declaring type (or one of its super types).
- implicit return statement fires a warning (BOO-703)

TODO:
- implicit downcast fires a warning (BOO-943) --- default mode? or strict mode only?
Cedric Vivier made changes -
Description Sometimes Boo is not conservative enough on certain defaults (which still makes sense for other/prototyping usages) that can lead to some errors slipping to a release unnoticed in (large) projects.

Strict mode introduces more conservative(safer) defaults and warnings.
Strict mode is disabled by default.

This compiler option is settable through:
- "-strict" with booc
- programatically by setting CompilerParameters.Strict to true
- "strict" argument with nant and msbuild tasks


When strict mode is enabled the following changes are enabled:
- default visibility is private like in C# (change made through BOO-1091)
- methods parameters types and return type of public methods (API) must be explicitely declared [to avoid unnoticed/unwanted binary-compat breakage]
- warns if a variable has the same name as a field of its declaring type (or one of its super types).
- implicit return statement fires a warning (BOO-703)

TODO:
- implicit downcast fires a warning (BOO-943) --- default mode? or strict mode only?
 Sometimes Boo is not conservative enough on certain defaults (which still makes sense for other/prototyping usages) that can lead to some errors slipping to a release unnoticed in (large) projects.

Strict mode introduces more conservative(safer) defaults and warnings.
Strict mode is disabled by default.

This compiler option is settable through:
- "-strict" with booc
- programatically by setting CompilerParameters.Strict to true
- "strict" argument with nant and msbuild tasks


When strict mode is enabled the following changes are enabled:
- default visibility is private like in C# (change made through BOO-1091)
- methods parameters types and return type of public methods (API) must be explicitely declared [to avoid unnoticed/unwanted binary-compat breakage] (BOO-1132)
- warns if a variable has the same name as a field of its declaring type (or one of its super types).
- implicit return statement fires a warning (BOO-703)

TODO:
- implicit downcast fires a warning (BOO-943) --- default mode? or strict mode only?
Cedric Vivier made changes -
Link This issue depends upon BOO-1132 [ BOO-1132 ]
Cedric Vivier made changes -
Description Sometimes Boo is not conservative enough on certain defaults (which still makes sense for other/prototyping usages) that can lead to some errors slipping to a release unnoticed in (large) projects.

Strict mode introduces more conservative(safer) defaults and warnings.
Strict mode is disabled by default.

This compiler option is settable through:
- "-strict" with booc
- programatically by setting CompilerParameters.Strict to true
- "strict" argument with nant and msbuild tasks


When strict mode is enabled the following changes are enabled:
- default visibility is private like in C# (change made through BOO-1091)
- methods parameters types and return type of public methods (API) must be explicitely declared [to avoid unnoticed/unwanted binary-compat breakage] (BOO-1132)
- warns if a variable has the same name as a field of its declaring type (or one of its super types).
- implicit return statement fires a warning (BOO-703)

TODO:
- implicit downcast fires a warning (BOO-943) --- default mode? or strict mode only?
 Sometimes Boo is not conservative enough on certain defaults (which still makes sense for other/prototyping usages) that can lead to some errors slipping to a release unnoticed in (large) projects.

Strict mode introduces more conservative(safer) defaults and warnings.
Strict mode is disabled by default.

This compiler option is settable through:
- "-strict" with booc
- programatically by setting CompilerParameters.Strict to true
- "strict" argument with nant and msbuild tasks


When strict mode is enabled the following changes are enabled:
- default visibility is private like in C# (change made through BOO-1091)
- methods parameters types and return type of public methods (API) must be explicitely declared [to avoid unnoticed/unwanted binary-compat breakage] (BOO-1132)
- warns if a variable has the same name as a private field of one of its super types (BOO-1133).
- implicit return statement fires a warning (BOO-703)

TODO:
- implicit downcast fires a warning (BOO-943) --- default mode? or strict mode only?
Cedric Vivier made changes -
Link This issue depends upon BOO-1133 [ BOO-1133 ]
Cedric Vivier made changes -
Resolution Fixed [ 1 ]
Status In Progress [ 3 ] Resolved [ 5 ]

People

  • Assignee:
    Cedric Vivier
    Reporter:
    Cedric Vivier
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: