Feature request: Multi-word properties

[bluelhf]

Is your feature request related to a problem? Please describe. Currently, properties must be valid ByteSkript identifiers. For most properties, this is fine, but consider something like the last login date of a Minecraft player. How might this be accessed in ByteSkript, given a player object? There are two existing solutions to this problem:

1. A custom expression. It's clear why this is undesirable: it's tedious, it requires a lot of boilerplate, and it duplicates the standard property syntax.
2. Use a non-english identifier as the property name. For the last login date property, lastlogindate could be used. This is obviously also suboptimal. ByteSkript is supposed to help you program with the power of words, not word.

Describe the solution you'd like Allow for spaces or other non-identifier characters in property names.

Describe alternatives you've considered See above. Alternatives exist, but they suck.

Additional context Care must be taken when implementing this — I'm not sure of the implications a change like this would have on ByteSkript's pattern matching.

[Moderocky]

I'm already considering changes for properties in 1.1 which is set to release before the new year.

Ideally I want to drop support for the %Object%'s <thing> form, since it's more irritating to support and to parse.

The grammar structure in 1.1 will probably be better for handling properties anyway;
a line like set the health of player to 10 can be broken down into a tree:

        set ... to ...
  the ... of ...     10
   health   player

The main issue it it's very difficult to narrow down what a property would apply to.
Something generic like name could apply to a lot of types (script, file, player, user, account, etc.) and it's difficult to see how these can be selected properly.

[bluelhf]

It seems to me that syntax like name of tool of player is inherently ambiguous: Should it be parsed as (name of tool) of player or name of (tool of player)?

Intuitively, the latter is obviously correct, as the player doesn't have a name of tool property — Perhaps an error could be shown to the user if they use syntax that ambiguously refers to one of several properties:

Ambiguous property reference: Please use either 'name of (tool of player)' or '(name of tool) of player' to resolve the ambiguity.

(Assuming such contextful errors are possible, and both properties, "name of tool" on Player and "name" on ItemStack exist)

This is a lot of work though. It could be easier to just explicitly specify how these properties are parsed (e.g. maximal munch) and leave it at that.