Forums Feature Suggestions Groups in the middle of code blocks

I'd like to be able to use groups in the middle of blocks of code (aliases, events, etc) so you can enable/disable a block of code in the middle of an alias or event.



Turning #coolfeature1 on would echo 1, as well as 2 and 3.
This could also be added without breaking most aliases beginning with # by only treating the line as a group if the second word is on, off or end.

Although suggested numerous times, nested groups would also be nice.

I'm guessing you meant for both group names for off and end in that example to be #coolfeature1

I can see the benefit of this, perhaps they could even be included inside popup menus.

I did
I tried to edit the post earlier but the edit time had already expired.

instead in the script that turns it on and off use like
menu menubar {
Cool Stuff
.Turn on Cool Feature : /set %coolthing1 1
.Turn off Cool Feature : /set %coolthing1 0
}
then for your script:

I'm not looking for workarounds, I already know many.
Thanks though.

This can get really complex (or just plain wrong) very easily. People will start using groups containing parts of control structures, and then find it strange the script doesn't do what they think it should do.

Here's an easy example:

But now consider cases where a group is partially over a while loop and partially over a trigger etc. It gets messy...

Is the possibility of making errors with it a reason not to implement it? Not really, but keep it in mind.

ps: you won't want the below code either I presume?

I think the idea merits as a great one, maybe difficult to implement into the script pharser, but still would allow a new method of coding.
example (which uses something like what you felt would be the problem with it)...



Based on whats passed , the while loop control is selected from within 3 groups. each group specific to the needs.

This suggestion & groups inside of groups would be great.

Hm... DaveC... From your example, I don't really see how it's useful. I mean, using that method, you could just as easily put the condition for enabling the groups right into your while statements. I'm not saying the idea wouldn't be good in some way, but from your example, I just really don't see how it helps.

Not adding a feature because a user might use it incorrectly is silly if you ask me.



That's the method I'm using now.

The reason I suggested this feature is that groups are the easiest, quickest and most descriptive way of turning a block of code on or off. I don't see why they should work any differently inside an event/alias/etc to what they do outside of one.

It was an example it was be design simplistic, just to show how a groups feature desecribed could be used.
Using conditional checks inside & within the condition of the while loop is wasteful, if those conditions well never change. Some conditional checks (not the ones shown in my example) can take huge sums of time to return a result, if one of these are encountered once in a script the script can carry on without any noticable delay, having that condition checked a few 100 times as the while loop loops back, is going to be unacceptable. These are the conditions i would be far more likely to actually implement the feature idea in.

Or another example (for better or worse?)



and then you could nest groups, because of parsing - so some groups would only appear if other groups are enabled.

Can lead to all sorts of interesting issues (and ideas)!

Cheers,

DK

I can see how groups inside events/aliases could be useful, as well as nested groups. Personally i think it could make the code very messy and a pain to read and debug. In any case, if it were to be implemented, i think a few enhancements/restrictions to the script editors built in syntax checker would be in order, fex... (that is, the bracket mismatch finder should also detect bad grouping layouts)

Probably the most important of which would be.. A group must end where it started :: That is, a group started globally (outside of any event/alias/etc) must also end globally, and in the same fashion groups started locally (inside of any event/alias/etc) must also end locally (in the same event/alias/etc that it started).

Should nested groups be cross-level? (refering to the example where only the function part and opening brace of the while was within the group, group start at top level, group end at 2nd level.. within while).

Depending on how hard and how much work this could be good or bad (the idea as a whole). If it adds too much to the script parser then it may infact caused it to be less efficient, rather than more efficient which seems to be part of the reason behind the suggestion.

This would probably confuse and frustrate a lot of new scripters using it incorrectly and not being able to figure out the problem in there scripts, as they would likely overlook the grouping tags as the possible problem. But as mentioned already this really is no good reason against it.

A simple example of where multi-level grouping could be useful...

some event {
#group1 on
while (something - something) {
#group1 end
#group2 off
while (something - something) {
#group2 end
#group3 off
while (something - something) {
#group3 end
some code here
}
final code?
}
something simple like this has both pro's and con's imo, there would be no restriction on having just one group enabled, more than one would instantly cause major problems. While at the same time if setup and initiated properly could be quite a useful alternative to a bunch of if statements and with inbedded while loops. (or several if statements used to set the conditions in the while)

Sorry guess i rambled on almost incoherantly, but those are my thoughts...

Basically i can see both the pro's and con's, personally i think the con's outweigh the pro's and would likely not use it a lot in my own scripts. But i would definately say that some code issue detection stuff for groups be added to the '{}' button in the scripts editor, which should check and report groups that do end and start at the same level. (outside event/alias/etc could be level 0, inside 1, and so on when inside of whiles/ifs/etc). My initial thoughts would be that by not allowing messy multi-level groups all over the place it would prevent most of the con's of the feature from occuring, however i guess it would also restrict the use somewhat.

I have to admit i have found myself on the odd occasion wishing i could use a group inside an event, but i can honestly say using it across 'mulitple levels' has never crossed my mind.

ok, ill stop typing now.