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

Support named expression/condition/effect parameters #134

Open
voximity opened this issue Aug 6, 2019 · 5 comments
Open

Support named expression/condition/effect parameters #134

voximity opened this issue Aug 6, 2019 · 5 comments
Labels
priority: medium Requires some attention, but does not need to be deployed immediately (most bugs) type: enhancement

Comments

@voximity
Copy link

voximity commented Aug 6, 2019

Is your feature request related to a problem? Please describe.
In the event I need to create an expression where two or more parameters may be ordered differently for two different parameters, e.g.

make %player% say %text% and
make %text% be said by %player%

the keywords expr-1 and expr-2 become ambiguous between the two patterns. A current solution would to be to check the matched pattern, but that would include hard coding in the patterns twice, and is overall just a gross solution.

Describe the solution you'd like
A way to name custom expression/condition/effect parameters. For example, in the creation of patterns, a solution could be as follows for the previously presented scenario:

make %player:speaker% say %text:message% and
make %text:message% be said by %player:speaker%
(where each parameter is defined like %type:name%)

Thus, in the definition of the effect, you could use a variable reference with some syntax to fetch the value of the provided parameter, like {:speaker} to refer to what would be expr-1 in the first pattern, and {:message} to refer to what would be expr-2. This syntax is obviously not the most ideal, but works with the idea I am trying to convey: named parameters prevent ambiguity.

Describe alternatives you've considered
Another solution would be to somehow number the parameters in the pattern beforehand and continue to use the [the] expr[ession][s](-| )%number% pattern, like make %player:1% say %text:2% or some similar syntax to define parameter position consistency throughout multiple patterns.

Additional context
Nothing belongs here.

@Moderocky
Copy link

You can compare the matched pattern, or the class of the expression, to determine which is which.
That said, it can get a little clumsy, so something like this might be nice.

An extension to this suggestion would be to allow expr-string and expr-player, as skript does with command arguments, when there is only one of a particular type. That would help in simple cases.

@voximity
Copy link
Author

voximity commented Aug 7, 2019

That's also a somewhat viable solution, until you end up having multiple parameters of the same type in interchangeable positions. The current comparison of the matched pattern would be considered bad practice in almost any other language or scenario, so I don't know why it would be the acceptable one here.

@btk5h btk5h added priority: medium Requires some attention, but does not need to be deployed immediately (most bugs) type: enhancement labels Aug 7, 2019
@btk5h
Copy link
Owner

btk5h commented Aug 7, 2019

This is actually a planned feature! This was even a utility that I wrote a few years back for Skript addons in general, and I'm excited to bring it to skript-mirror in the future.

The plan is to be able to name expressions within the pattern and be able to access the expression as a local variable {_name}, which is very similar to how Skript functions work as well.

I remember that for some reason, there was a lot of negative feedback to this idea when this was discussed in the past. If anyone has any issues with this approach, I think organizing any arguments here would be a good idea.

@voximity
Copy link
Author

voximity commented Aug 7, 2019

I am a fan of the usage of local variables for fetching passed arguments! I'm very curious, however, about what syntax you have planned for modifying the patterns in a way that would allow named parameters to be possible.

I'm also curious over what arguments people might have against this. Additionally, this feature would come as semi-optional. As long as the "matched pattern" expression was kept in place, developers who use this method presently would not be forced to switch over to the named parameter convention.

@btk5h
Copy link
Owner

btk5h commented Aug 7, 2019

The syntax you described originally is pretty much exactly what I had in mind.

I think the main argument against this had something to do with the use of local variables? I don't want to misrepresent that argument, but I don't recall that conversation bringing up any massive issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority: medium Requires some attention, but does not need to be deployed immediately (most bugs) type: enhancement
Projects
None yet
Development

No branches or pull requests

3 participants