sassoftware/jsl-hamcrest

Mangle member variables in classes with a prefix to reduce collisions

Opened this issue · 5 comments

Currently you can collide with a member variable in a class and get an error stating that a member variable was attempted to be accessed from a function. Mangling our member variables with a prefix should help to reduce the chance of this happening.

If you have a prefix that you would recommend, I can put in a pull request for this.

Are you opposed to using a single underscore _ as a prefix? This would only apply to regular member variables and not methods (except for methods meant to be "private").
Example:

Define Class(
	"UtIsMatcher",
	Base Class( "UtMatcher" ),
	_inner = Empty();
	_init_ = Method( {inner},
		this:_inner = inner;
	);
	matches = Method( {test expr},
		this:_inner << matches( Name Expr( test expr ) );
	);
	describe = Method( {},
		this:_inner << describe();
	);
);

With our changes in PR #47, I think this problem becomes a bit easier to avoid, but I still think it is a worthwhile thing to do.

That seems a little too generic to me. I have definitely seen customers put a _ before their variables. Also, why would it not be methods? Even if it doesn't cause the problem, wouldn't we want consistency?

I agree with @VDFaller that both regular members and methods should be mangled. This is because either is possible to access using an unqualified name in a test expr. However, I think we should limit this issue to regular members and file a separate issue for methods. Changing the methods requires changing the published interface for Matchers and Reporters and should not be taken as lightly.

As for the mangling itself, what about both a leading and trailing underscore like _inner_? There is a little potential for conflict with the "special class methods" here. Or maybe _ut_ as in _ut_inner.

@emccorkle If all of the globals are already ut, I'd say it makes sense to mangle them with either ut_, ut., or just ut. I'd lean toward the former since all of the globals are already ut and we wouldn't want some collision there, and ut. makes it feel too much like it's an object.