Re: New assignment operator?

Andre McCurdy

On Wed, Jun 16, 2021 at 11:26 AM Phil Blundell <pb@...> wrote:

On Wed, Jun 16, 2021 at 11:05:06AM -0700, Andre McCurdy wrote:
I'm not sure I understand this. Why is using the _forcevariable
override somehow worse than inventing a new assignment operator to do
the same thing?
Because _forcevariable isn't positional. It means "no matter what
else appears in the metadata, either before or after this assignment,
I want the variable to end up with this value". I don't think that's
ever an appropriate assertion for something in oe-core to be making.

Obviously if you have two _forcevariable overrides on the same
variable then one of them is going to lose so to that extent it's
making an impossible promise. But other than that, it just doesn't
play very well with others, not least because its effects can't
be undone. Which is more or less the original problem that we
started with: all we've done is take it up a notch, and this is
exactly the kind of arms race that I mentioned in my first email
on this subject.

Richard's !=! or whatever we want to call it at least has the merit
that it overrides what has gone before but can itself be overridden
by what follows.
I don't think users generally have a good grasp of the concept of
"what has gone before". They expect = to override ?= and _myoverride
to override = and if the ordering of those assignments can change
their effect then it's a bug rather than a feature.

I'm sure the advanced users reading this thread will be able to dream
up situations where an assignment operator which forcefully overrides
all overrides but can then be overridden again with another assignment
can be used in some creative hack somewhere... but it's not making OE
any better for the average user.

Join { to automatically receive all group messages.