Lockable variables

General Discussions
#1

I was just thinking and I had an idea for a concept, but I wanted to get some input from other people before putting it to use.

Concept: lockable variables. You set a locked flag and then you can set it’s value.

[icode]LockedVariable.java[/icode]

public class LockedVariable<T> {

	private T value;
	
	private boolean locked = false;
	
	public LockedVariable() {
		
	}
	
	public LockedVariable(T value) {
		this.value = value;
	}
	
	public void lock() {
		locked = true;
	}
	
	public void unlock() {
		locked = false;
	}
	
	public void setValue(T t) {
		if (!locked) value = t;
	}
	
	public T getValue() {
		return value;
	}
	
}

Any feedback on whether this idea is worth putting to practice would be appreciated :slight_smile:

CopyableCougar4

#2

What’s the point?

#3

For global constants, so that they could be kept from being set at certain times. It was just a thought, I just wanted some feedback to know if this idea is usable.

#4

With reflection, nothing is immutable.

#5

Point taken, but the concept would be for variables where you wouldn’t be using reflection (because the same programmer who made the lockable variables would not use reflection to set them).

#6

[quote]Point taken, but the concept would be for variables where you wouldn’t be using reflection (because the same programmer who made the lockable variables would not use reflection to set them).
[/quote]
Well then why does the programmer need to use the locked variable in the first place? They would just know when not to modify the variable.

#7

That’s your problem right there.

#8

I guess the concept should be trashed, it seems like a programmer who knows their way around a given project should have no need for this idea.

#9

Not to mention the fact that it doesn’t tell you when you tried to set a value that you shouldn’t have, it just fails silently, leading you on a wild goose chase until you remember about your weird extra global state hiding in your variables.
A programmer wants better abstractions if any are needed, not leakier ones.

#10

Uh, the final keyword? o_O

#11

That and defensive getters if you’re really concerned.
I’ve been becoming more and more of a fan of the “immutable by default” tend in prog-langs recently. Makes life simpler.

#12

Well the original intent was one that could be locked an unlocked, where I believe final can only have the initial value (but if I’m wrong please tell me)

#13

I can’t see it being useful if users aren’t going to be interacting with your codebase (scripting, etc).

#14

I understood this to be more like a Mutex. That has a lot more use if that’s what you are trying to do, but it already exists so use that instead.

#15 

public void setValue(T t) {
     if (locked) throw new IllegalStateException("Value is locked!"); 
     value = t;
}

I have used something like this in my recent project. It has worked like a charm. When you begin writing big and complex abstracted code things like this are really helpful. Helped me solved some possible bugs without almost any effort at all. I just block some states and boom there you go you get an exception when you shouldn’t have accessed the variable.

#16

You can simply setup a breakpoint to determine/prohibit the execution of a certain piece of code.

#17

I had a class “FlagWord” so I don’t think break point is very viable in such situation.

#18

Naturally.