Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rename takeFlag() or revise its behaviour to match its current name #256

Open
Mouvedia opened this issue Oct 19, 2013 · 6 comments
Open

Comments

@Mouvedia
Copy link
Member

Finally we have the takeFlag() function which deactivates an existing flag to activate it on the current element(s).

Check the example from the spec.

Currently it activates the flag no matter what. The flag needs to be activated on at least one of the elements matched by the selector.

@veosotano
Copy link
Member

The flag needs to be activated on at least one of the elements matched by the selector.

Why?

Usecase: elements of a menu. You click on one and nothing has been selected yet (maybe the page you're on right now doesn't appear in that menu). You want to activate that menu item, doesn't matter that nothing has it yet.

This should be discussed in a spec meeting if necessary.

@Mouvedia
Copy link
Member Author

@veosotano It seems clear from the name that you have to get the flag from something else. Well that's what valerij and I understood at least. I don't understand how it could activate a flag if it didn't actually take it first.

BTW to clarify any misunderstanding when I say "matched by the selector" I mean the inner selector (of the function).

@veosotano
Copy link
Member

If you follow the metaphor into the real world, yes, there needs to be something somewhere to be able to take it.

But we are dealing with a language for designing an interface, and in the interface world, creating the flag with takeFlag(), even when no element has it yet, is perfectly reasonable. It would be confusing and very much less useful if it wasn't the case.

Remember also that takeFlag() has always been just an alias for

unflag(foo of !@this), flag(foo);

I'd be interested in how you would use takeFlag() on a menu without active (w flag applied) elements, if it was behaving like you propose, since you could never activate any element, because you "can't take the flag from anywhere"... You would need to use flag() only the first time or something... Very complicated.

On 20/10/2013, at 01:17, "Marc G." [email protected] wrote:

It seems clear from the name that you have to get the flag from something else. Well that's what valerij and I understood at least. I don't understand how it could activate a flag if it didn't actually take it first.


Reply to this email directly or view it on GitHub.

@Mouvedia
Copy link
Member Author

unflag(foo of !@this) is only one case, the selector can take anything.

I don't think it's a good idea to have a function which has 2 behaviors. Unless we rename it to something that makes sense for both cases. Maybe you want switchFlag() cause that would enable the behaviour you want. It covers both meanings of activation and replacement.

@veosotano
Copy link
Member

Why do you do always do all this hair-splitting? We renamed the function on your behest (it was captureFlag at the beginning, remember?), now you say the name doesn't sound what it does...

This function was proposed to do those two functions in the first place. It's really useful because it greatly simplifies a very common task, which is switching active elements in a menu.

So, stop it already.

On 20/10/2013, at 12:36, "Marc G." [email protected] wrote:

unflag(foo of !@this) is only one case, the selector can take anything.

I don't think it's a good idea to have a function which has 2 behaviors. Unless we rename it to something that makes sense for both cases. Maybe you want switchFlag() cause that would enable the behaviour you want.


Reply to this email directly or view it on GitHub.

@Mouvedia
Copy link
Member Author

which is switching active elements in a menu.

Exactly my point.

Capture would have the same problem. I discovered that behaviour you are saying was intended by testing the function and thought it was a bug. Also you could try asking around you, you will see that this behaviour is not expected if you are using that name.

So I propose that this ticket be repurposed to "rename takeFlag()".
And my proposal is switchFlag() which meanings would cover all behaviours adequately.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants