This is being worked on. I added code to allow addons that use FakeStatusBar (which is like Blizzard's, only without a significant amount of suckage) to set alpha colors.
Pusikas, it could easily be done with
[if Class:In("Priest", "Mage", "Warlock") then "Squishy"]
I don't really want to add comprehensive list manipulation to DogTag.
Dragon, DogTags are compiled into separate lua functions, interpreted only once, not multiple times. Also, those lua functions are compiled to lua bytecode, which is the best we can do.
The lua/icon-style if then else is reasonably sane except that you'll need an 'end' of some sort. I still think you're making things more complicated than they need to be by not treating dogtag like a functional language.
Actually, seeing as DogTag doesn't have more than one statement per bracketed sequence, end is never required, even in complex if-then systems.
My current thought process has led me to believe that the following idea is the sanest of what I've heard (note, I'm fully willing to be proved otherwise):
If syntax:
[if Condition then Result]
If-else syntax:
[if Condition then Result else Other]
Separate and from if
[Alpha and Bravo], [if Alpha and Bravo then Charlie else Delta]
I think that separation will clear up a lot of issues, since instead of [Alpha ? Bravo ? Charlie ! Delta], you get the more understandable syntax above.
There would also be or as well as and, along with all your favorite comparators such as =, <, >, etc.
I'm also going over in my mind to have lower levels of bracketing use different shapes, e.g.
[if Alpha and (Bravo or {Charlie and [Delta or Echo]}) then Something else "Howdy"]
or perhaps only [] on the outside and () on the inside:
[if Alpha and (Bravo or (Charlie and (Delta or Echo))) then Something else "Howdy"]
or perhaps [] everywhere
[if Alpha and [Bravo or [Charlie and [Delta or Echo]]] then Something else "Howdy"]
or some other symbols, i.e. we don't need to keep [].
Separately, with regards to modifiers being postfix (as it is now) or prefix (as pastamancer has suggested), frankly I don't see any reason why it couldn't function as both. [Green("Hello")] could be just as supported as ["Hello":Green], and up to the user as to what will make more sense for them.
Hoern, that actually already exists with [PercentHP < 10 ? Text(Die Scum) ! Text(Just a flesh wound)]. Uses ! instead of : since : is used for piping.
The main issue that I see is that simple if-then and if-then-else statements are necessary, and currently handled by the [Alpha ? Bravo] and [Alpha ? Bravo ! Charlie] syntax, but that is complex and unintuitive for some people. I just don't know how to make it better and turning it into Lisp doesn't seem like the best solution to make things easier for users.
I could have something like [If(Alpha, Bravo)] or [If(Alpha, Bravo, Charlie)], but I don't think that that necessarily provides a better landscape.
Going back to pastamancer's post about Lisp, I think that DogTag really only has two large syntactical ideas behind it.
First is piping, as some may know from bash. echo 'alpha'|sed 's/p/s/' will pipe the results of echo 'alpha' into sed 's/p/s/'.
Much in the same way [CurHP:Green] pipes the results of CurHP into Green.
Second is basic logic statements, if something then do something else do another end, which DogTag has done with [Alpha ? Bravo ! Charlie]
There's not really anything beyond this, there's no list manipulation, no iteration.
1. Make it possible to do things like [IsPlayer ? Level Class ! Classification CreatureType].
Instead of [IsPlayer ? Level Class ! Classification CreatureType], my thought was for it to be something like [IsPlayer ? Level .. " " .. Class ! Classification .. " " .. CreatureType] (Note: the concatenation operator could change)
Another thing I was thinking about, possibly making tags more verbose, e.g. instead of [CurHP], it might be [CurrentHealth] or even [Current Health] or just [Health], with others being [MaximumHealth] or something like that.
I also think there should be a consistency to the naming of tags, as some are [HasSomething] or [IsSomething] where others are just [Something], e.g. [Resting] instead of [IsResting], but there's [HasSoulstone] and the like, so that should be made consistent.
Again, I'm just throwing ideas out there and I want people to disagree with me so that the best solution can be achieved.
I'm also thinking it could be better to make the ternary syntax more "english" instead of being a bunch of symbols.
[Alpha ? Bravo] could become [Alpha and Bravo]
[Alpha ? Bravo ! Charlie] could become [Alpha and Bravo else Charlie]
[Alpha | Bravo] could become [Alpha or Bravo]
I'm not sure whether this is an improvement or not.
Currently, arguments of tags are seen as literal, but internal expressions can be done by using brackets with the syntax [Alpha([Bravo])].
I kind of want to remove the internal bracket and instead have [Alpha(Bravo)]. To do a literal string in that case, you would do [Alpha("Charlie")] or [Alpha('Charlie')].
I could also eliminate the Text tag, as currently you use [Text(Hello)], but that could become [Text("Hello")] or just as easily, ["Hello"]
With this new system, I could also add support for multiple arguments, e.g. [Alpha(Bravo, Charlie)] or [Alpha("Bravo", "Charlie")] or something along those lines.
0
0
0
[if Class:In("Priest", "Mage", "Warlock") then "Squishy"]
I don't really want to add comprehensive list manipulation to DogTag.
Dragon, DogTags are compiled into separate lua functions, interpreted only once, not multiple times. Also, those lua functions are compiled to lua bytecode, which is the best we can do.
0
Actually, seeing as DogTag doesn't have more than one statement per bracketed sequence, end is never required, even in complex if-then systems.
0
If syntax:
[if Condition then Result]
If-else syntax:
[if Condition then Result else Other]
Separate and from if
[Alpha and Bravo], [if Alpha and Bravo then Charlie else Delta]
I think that separation will clear up a lot of issues, since instead of [Alpha ? Bravo ? Charlie ! Delta], you get the more understandable syntax above.
There would also be or as well as and, along with all your favorite comparators such as =, <, >, etc.
I'm also going over in my mind to have lower levels of bracketing use different shapes, e.g.
[if Alpha and (Bravo or {Charlie and [Delta or Echo]}) then Something else "Howdy"]
or perhaps only [] on the outside and () on the inside:
[if Alpha and (Bravo or (Charlie and (Delta or Echo))) then Something else "Howdy"]
or perhaps [] everywhere
[if Alpha and [Bravo or [Charlie and [Delta or Echo]]] then Something else "Howdy"]
or some other symbols, i.e. we don't need to keep [].
Separately, with regards to modifiers being postfix (as it is now) or prefix (as pastamancer has suggested), frankly I don't see any reason why it couldn't function as both. [Green("Hello")] could be just as supported as ["Hello":Green], and up to the user as to what will make more sense for them.
0
The main issue that I see is that simple if-then and if-then-else statements are necessary, and currently handled by the [Alpha ? Bravo] and [Alpha ? Bravo ! Charlie] syntax, but that is complex and unintuitive for some people. I just don't know how to make it better and turning it into Lisp doesn't seem like the best solution to make things easier for users.
I could have something like [If(Alpha, Bravo)] or [If(Alpha, Bravo, Charlie)], but I don't think that that necessarily provides a better landscape.
0
First is piping, as some may know from bash. echo 'alpha'|sed 's/p/s/' will pipe the results of echo 'alpha' into sed 's/p/s/'.
Much in the same way [CurHP:Green] pipes the results of CurHP into Green.
Second is basic logic statements, if something then do something else do another end, which DogTag has done with [Alpha ? Bravo ! Charlie]
There's not really anything beyond this, there's no list manipulation, no iteration.
0
CSS has concatenation by juxtaposition, and it seems like it could simplify things for users quite a bit.
0
Instead of [IsPlayer ? Level Class ! Classification CreatureType], my thought was for it to be something like [IsPlayer ? Level .. " " .. Class ! Classification .. " " .. CreatureType] (Note: the concatenation operator could change)
0
0
Chinchilla:AddTrackingDotStyle("My Blip", L["My Blip"], [[Interface\AddOns\HunterZBlip\MyBlip]])Just put that in a lua file, make a toc file, and make the texture.
0
I also think there should be a consistency to the naming of tags, as some are [HasSomething] or [IsSomething] where others are just [Something], e.g. [Resting] instead of [IsResting], but there's [HasSoulstone] and the like, so that should be made consistent.
Again, I'm just throwing ideas out there and I want people to disagree with me so that the best solution can be achieved.
0
e.g.
[Leader] => "Leader"
[MasterLooter] => "True"
I think it'd be nicer if everything worked with each other instead of having inconsistencies.
0
[Alpha ? Bravo] could become [Alpha and Bravo]
[Alpha ? Bravo ! Charlie] could become [Alpha and Bravo else Charlie]
[Alpha | Bravo] could become [Alpha or Bravo]
I'm not sure whether this is an improvement or not.
0
Currently, arguments of tags are seen as literal, but internal expressions can be done by using brackets with the syntax [Alpha([Bravo])].
I kind of want to remove the internal bracket and instead have [Alpha(Bravo)]. To do a literal string in that case, you would do [Alpha("Charlie")] or [Alpha('Charlie')].
I could also eliminate the Text tag, as currently you use [Text(Hello)], but that could become [Text("Hello")] or just as easily, ["Hello"]
With this new system, I could also add support for multiple arguments, e.g. [Alpha(Bravo, Charlie)] or [Alpha("Bravo", "Charlie")] or something along those lines.