Multi-value properties: positions' custom names

[vprimachenko]

the thing we put in the square brackets should be related to the property rather then its value(object inside). Eg a weather app

body {
    background["sky"]: @normalSky;
}

later on i can override its value without renaming:

body:rain {
    background["sky"]: @rainSky;
}

and background["city"] would stay "city" no matter if i put the skyline of Chicago or Canberra in it.

Conta: how do one make multiple such assignment in one rule?
well while this syntax

    background["sky"]: @normalSky;
    background["city"]: @defaultCity;

works but might be unsatisfiable a discussion regarding an 'assign at once' syntax was held ages ago and mentioned PHP like 'fat arrow', but with #106 in mind one could think of

    background:"sky"=@normalSky,"city"=@defaultCity;

[Mouvedia]

To the persons wondering what he is talking about, he wants to have custom references to the positions in the property value stack. I have edited the title to make that clear.

[Mouvedia]

If we were to implement this, the name assigment of the position needs to be granular (you could name one position and leave the others unnamed). The naming will be scoped and will have its own declaration (can't be bound to the initial value). Using the reference function for the same property will preserve the name as well:

//preserves the name
background: ref(background[:nth(2)] of selector);

//doesn't (the value doesn't have a name anymore)
color: ref(background[:nth(2)] of selector);

That said how would you assign a name to a position?

Here's what I propose:

background: value1, value2, value3;
// values works about the same way as the cascade property
background.values[2]: "nameHere";
// just in case you dunno this is equivalent
background.values[:nth(2)]: "nameHere";

// now you can use it to replace value2
background["nameHere"]: valueX;

[vprimachenko]

prop[_,"sky",_]:texture1,defaultSky,texture2; where _ stands for ignore like in GO

[Ragnis]

background["nameHere"]: valueX;

I don't think this is such a good idea. It could easily be confused with
the dot notation.

background.values[2]: "nameHere";

As a user I would expect that to set the second value of background to
nameHere.

[Mouvedia]

You mean you would confuse
property.values[2]: "nameHere";
with
property[2]: "nameHere";
?

I guess that could be confusing if you don't grasp the concept behind the value selector.
In the first one you access a property which would be present on all properties that accept multiple values called values that is storing their names as strings. On the second example, iirc, you reset the second value of the property.

@Ragnis In the case of background you have to agree that it wouldn't make sense to have a string as a value…

[Mouvedia]

@vprimachenko the problem with your last proposal is that it doesn't satisfy what Iv listed up there: it requires us to list the values everytime. It needs to be separated. But here's something that can be done about it:

prop[default,"name",default]: current;

It's not convenient if you wanna name only one value. It needs to be granular.

[vprimachenko]

it requires us to list the values everytime

why?
usecase: i want to set three backgrounds, one of them should go to a named slot

background[_,"foo",_] : bg1,bg2,bg3;

usecase: i want to set two backgrounds, and later add new one to a named slot

background: bg1,bg3;
background["foo"] : bg2;

where background : defaults to background[_,_] :
this syntax is inspired by "Multiple assignment" in Lua,Python,etc and range operations in Matlab, _ as "ignore" placeholder is used as such in GO

usecase: i want to remove all existing backgrounds and specify new one edited

background[*] : bg4; //maybe [:all] or [...]

usecase: i want to add a new value to an unnamed slot

background[] : bg5;

inspired by PHPs "append to array"
usecase: i want to remove a value i put into an unnamed slot

then you should have gave it a name, thats what them are for

  background[2 *or* "name"]:; //use default value

[Mouvedia]

Sorry but your second example wouldn't work. You would end up resetting the property and not add a new value. To add new values you need to use the current keyword (check the specification). Like I said in my second comment you can't assign a name to a position and set the background at the same time: it needs to have its own declaration. If you have a proposal that meet these requirements please share.

[veosotano]

Funcod, you've got something something wrong. VP wasn't saying to assign a name to an object, he was setting an object with that name (slot) to the background property. It's not wether it would work, it's a matter of wether we like the syntax, which is another matter.

On 17/09/2013, at 22:55, "Marc G." notifications@github.com wrote:

Sorry but your second example wouldn't work. You would end up resetting the property and not add a new value. To add new values you need to use the current keyword (check the specification). Like I said in my second comment you can't assign a name to a position and set the background at the same time: it needs to have its own declaration. If you have a proposal that meet these requirements please share.

—
Reply to this email directly or view it on GitHub.

[Mouvedia]

I perfectly understand what he wants. He wants to assign a name to the position (totally independent of its current value). And you didn't understand why it wouldn't work. To add a new background and end up with 3 values he needs to use the current keyword. Since he's trying to assign the name at the same time maybe you didn't realize it wouldn't work.

Anyhow it's not a matter of liking the syntax, we want something that blends with what we currently have and which would be convenient to use. For that you need to separate the name assignment from the property setting.

[vprimachenko]

lets break background["foo"]: bar; down: it works just like background["foo"] = myBg; would in javascript:
background"foo"] 'returns' a reference to the 'slot' with the name "foo", allocating one if not present
: bar; assigns a value to the 'slot' 'returned' by left side;

background[_,"foo",_] : bg1,bg2,bg3;: multiple assignment like in Python
background[_,"foo",_] allocates 3 'slot's, gives the second one "foo" as name, 'returns' the 'slots'
: bg1,bg2,bg3; assigns 3 values to 3 'slots'

terms in single quotes are placeholders due my lack of better word

[Mouvedia]

allocating one if not present

Where? Which position would it take? The last one by default?

It seems you don't want to assign a name to a position but a name to a value (which, the value, can later be changed) which means it will be difficult to track the position of the named value. IMO we are not gaining much but I am not against it. On the other hand, like @veosotano said on IRC, I don't like the multi assignment syntax.