object definition syntax change

[vprimachenko]

now we use

@type myFoo {}

i propose we switch to

myFoo = @type {}

My arguments are:

1. name definition per assignment is common in other languages as PHP($foo = ...), Javascript(var foo = function(){} pretty similar neh?), etc
2. searchable without a regex enabled find, which is advanced feature (notepad++, browsers CTRLF don't have it) = @ vs current @[::alpha::]+ =
3. solves a possible conflict with property stacks(its how i call that background[2] stuff), so prop[foo] : @type bar {}; cant happen (saves us a console warning + priority decision)

Contra:

1. new syntax is harder to tell apart from a valid selector (implimentation detail)
   • sure but the parser is doing a Sisyphus level heavy-lifting already, and new syntax is doable
   • add yours here

[vprimachenko]

shame on me, just realized i should have done this as comment on #78

[Mouvedia]

shame on me, just realized i should have done this as comment on #78

No that is not about this. I should have put a description. We need to have the regex of a valid "identifier".

prop[foo] : @type bar {};

This is invalid. Either you wanna reset the properties (note the plural) of an object (named foo) property[foo]: { } or you wanna set one of the properties of foo property[foo].propertyOfFoo: value;.

So your third point is moot. Your second point is sound though.

[vprimachenko]

third point resulted from an issue veo pointed out in irc, which was the primary reason for this proposal

[Mouvedia]

And I am telling you, he was wrong. This is invalid.

Concerning your proposal, here's why we can't have it:

element {
    // this is valid but selects nothing (because @this isn't a sibling of child1)
    child1 = @this { properties here }
}

The problem with that new syntax is that we would only be able to use it in the root scope (since the root has no siblings). That would complicate things without much to gain (compared to the current solution).

[vprimachenko]

if #107 gets resolved so prop[...] ignores the objects name this is an nonissue

[veosotano]

I have no idea what @Mouvedia is talking about: property[foo]: { } -> this is completely new to me.

As he is sort of pointing out, `=`` is used as a siblings combinator, which I like quite a lot, it would need to be substituted with another char.

On the other hand, there is also the & notation.

@type myobj1 { foo: bar; & myobj2 { //inherits foo:bar here } }
@type myobj1 { foo: bar; } & myobj2 { //same type as myobj1 } 

How would those be handled?

[Mouvedia]

@veosotano I know it's off topic but do you agree that it shouldn't be allowed to assign an object and declare its name at the same time?

e.g. prop[foo] : @type bar {};

Either you are using an object already declared before and hence it has a name or you just use the object directly ( @type { }) as the value.

IMHO the only logical usage for prop[foo] : would be to edit the properties of foo.

So back to your proposal, I vote -1 for now.