Resolved
| |||||||
This suggestion is simple. Allow code like "MyVar = SomeValue" to return SomeValue. This would allow for cleaner code, for example the following
var/Piece = GetNextEmptyNetworkPiece() var/Piece This would also help to reduce code repetition as shown. Since other operators (|, ||, ==, etc) already do this, making = return a value would also improve language consistency and ease of use. | |||||||
this particular example can't use do/while; GetNextEmptyNetworkPiece() returns null if there aren't any, meaning that while block may not execute in the first place.
Technically this should/would also allow code blocks like Var1 = Var2 = SomeValue Var1 = SomeValue | |
I'm in two minds about this.
On the one hand, there's the aforementioned convenience. On the other, you have a bit of a debate about whether or not it makes sense for BYOND to be the kind of language that implements a system of side-effects, which is basically what the r-value assignment stuff does. As a learning language, you'd want to avoid permitting side effects, if possible, as it adds another layer of programmer interpretation to code. In your example:
while(Piece = GetNextEmptyNetworkPiece())
There's three operations at work.
For others, the pattern carries a bit of a trip for new programmers, as they tend to read the condition of a loop as though it's static, or fail to appreciate the consequence of it being re-evaluated on each cycle. You also have the rookie mistake problem, that = and == are probably synonymous to new programmers. Currently = will give them a fairly unexciting result in a loop. | |
Topkasa wrote:
Technically this should/would also allow code blocks like Any usage outside of conditional statements seems pointless. Not only does it look weird, but it lessens readability. I'm thinking that if this were added, it'd only be for conditionals or in certain locations, just because there's no real functional gain anywhere else. | |
Well, if you make operations pass through their r-value like that (so, unary operators are actually implicitly binary), you'd probably do that wholesale. It's actually what makes this a surprisingly bigger feature in terms of implementation than it seems.
| |
Operators are operators, SSX. The logical operators behave no differently from the arithmetic (or even the "in" operator) aside from return value, so why should the assignment?
IMO if DM initially supported this syntax it would probably seem as ugly as abusing the colon or goto. The language supports it, but it's not intuitive except maybe for specific cases, maybe. | |
Currently, = gives an error in a conditional. I think we can disregard the problem of side-effects, as they're just as relevant as in the original code sample.
The second example, of Var1 = Var2 = SomeValue Var1 = (Var2 = SomeValue) Var1 = Var2 == SomeValue ALso, while goto/colon abuse can be bad, I fully believe that their use should be dictated by the situation, and not ideals - give programmers the option to use them, and encourage judicious use. | |
I don't particularly think giving it this pass-through behaviour is inherently bad per-say, but I wouldn't put it in code examples on Developer Help, or in demos and tutorials, for instance, just to spare the newbie confusion. The colon variable referencing for instance is more of an anti-pattern than this is, this is mostly syntactic sugar.
An interesting concept, probably you'd want to do it as part of a wider review of the operators (and operator overloading, perhaps?). So not exactly ... quickly implemented. --- Just spied me a new post --- Well, the option thing is the point for debate, and why I'm in two minds. Unlike say ... C++ or Java, DM's roots and still probably it's primary scenario is being a first language to people, and consequently a learning language. Learning languages tend to want to reduce the options available to a programmer, to ones that they feel 1. make it easier for the programmer to learn or 2. encourage good practice. This obviously isn't a feature that contradicts 2 like gotos do for readability, but it can I think contradict 1, basically by making the assignment operation multi-effected, and allowing it into conditional statements, where a very new programmer might well naively put it, meaning == instead. | |
Yeah, I would support maybe only noting this behaviour in a small section and not making noise of it in order to reduce confusion in new developers.
| |
Then there's the issue of new developers using = in conditionals when they meant ==. No error, as it's proper syntax, but it's probably not what was intended. Equals is equals, what's this double equals thing? I can see the junk Help posts already (even though I doubt this kind of change to the language is even feasible due to Dancode).
| |
That doesn't seem like a valid reason to restrict more capable programmers, though. While being easy to learn is important (and DM is), in order to truly shine the code needs to allow veteran coders to exercise their skills with an absolute minimum of restriction.
| |
Well yes, that's the case I'd be more concerned about, Kaio, as it's a more likely issue for very new programmers. I think if you gained more out of it, or this wasn't such a learning language, then I'd disregard that as an issue.
--- The thing is, Topkasa, this is syntactic sugar. You don't particularly gain any expressive power through this feature, it doesn't make any particularly tasks significantly easier, I think? | |
I agree that this is 'sugar', but it has advantages in improving readability, decreasing code repetition, language flexibility, allowing set-and-test in loops and ease of integration for programmers experienced in C or C-like languages.
| |
Not ... enormous advantages in that regard though? There will be the aforementioned trip-up for new programmers. BYOND does tend to balance in their favour, unless there's a good argument to be made that something should be done at their expense. In another platform, you'd probably go in favour of this feature, because the market is different.
This is mostly why I said this would be interesting as part of a wider look at operators and their capabilities, as it would make sense in a wider "Alright, well, assuming we're targeting different people" perspective. | |
That 'trip-up' will catch a newer programmer sooner or later unless they stay firmly within the realm of DM and Basic, really. Every other language I've touched has used == and = to mean very different things, and learning to recognize that difference will be important for any budding programmer. DM is a very easy language to learn, but preparing new coders for the sorts of patterns they will experience in basically every other c-style language cannot possibly be a bad thing.
[12:03:23] <@Inuyasha> newbies confusing = and == This is a potential solution to the problem, as well. | |
Nadrew resolved issue (Not Feasible)
| |
Oh.
| |
Well, that is somewhat unfortunate but oh well.
| |
Changing this aspect of the compiler is incredibly non-trivial and definitely not worth the time and effort required to do it.
| |
assignment within conditional statements
It's something that appears in other languages quite often, I think its been requested before. Not sure how long ago but it seems like a big and not trivial change for the compiler,
also for your example you could probably? use a do while, instead of a while