View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000762 | LDMud 3.5 | LPC Language | public | 2010-11-07 06:25 | 2021-04-16 22:09 |
| Reporter | _xtian_ | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | won't fix | ||
| Summary | 0000762: explicit identity operator for pointer equality | ||||
| Description | The motivation is as follows: Sometimes programmers compare two complex datatypes with == and either forget that this only compares "pointers" or just don't know it. With LPC we work in an environment where most of the coders are beginners in either programming in general or in LPC specifically, so we should always try to minimize common mistakes with adequate language features if we can (compare to Java omitting pointers and memory allocations). I think we agree on this. My proposition: --------------- 1.) When comparing two complex datatypes (array, mappings, structs) with == (equal) the Driver throws a warning to note that one is comparing pointers, not elements. Note the use of a warning that will not directly break existing code. 2.) introduce a new operator === (identity) which explicitly only compares pointer equality. This should then be used for the above complex datatypes if the programmer intended such a comparison. If on the other hand the programmer intended a per-element equality he needs to fall back to a mudlib sefun, if such a function is provided. (per-element equality is a whole different topic) | ||||
| Tags | No tags attached. | ||||
| related to | 0000266 | closed | Value comparison '===' for mappings/arrays |
|
|
Note: per-element equality is not trivial. One would need to provide different equality-functions when allowing element-doubling or not (sets), recursion through sub-complex datatypes or not - and how to handle possible loops in recursion. All of these have valid applications. (Avalon atm just provides non-recursive set/non-set checks for arrays atm) |
|
|
I have concerns that 3 equal-sign-operators (=, == and ===) would make life (learning language, reading source code) more complicated instead of easier. It doesn't bring new functionalities, it only gives a warning that == only compares pointer equality. That is something that could already have been a part of an LPC training (as it is true now for == and will be true for == and ===). What's the opinion of others on this? |
|
|
I agree fully with Gnomi. The mode of comparison done with == should really be part of LPC training as well as the difference between the pointer-based types and the basic types. You anyway have to know that if you pass the pointer-based types around... And there isn't anything we might do about the that. And besides the added complexity by the additional operator I see the very real risk of mis-reading these operators during code review: = and == as well as == and === have the potential to look very similar on the screen if you don't look very carefully (granted: exchanging == by = is much more harmful). Another point: I think, there may be really a lot of warnings with == then. And my experience is that many wizards just start to ignore the warnings if there are too many. |
|
|
I agree that there should be no new operator for the reasons given by Gnomi and Zesstra. As for the per-element equality as mentioned in _xtian_s note: it might be worthwhile to consider implementing an efun for that but that should be discussed in a different issue. |
|
|
+1 for no new operator |
|
|
I find that most LPC users are programming beginners and have always appreciated that fact, since it lowers the learning curve and makes it easier to win and keep new wizards for our MUDs. In my eyes, to say that the difference between pointers and value-types should be part of basic training is overestimating the programming skills and capacity of most wizards (keep in mind that LP-MUDs dont really make a difference between 'itemizers' and 'programmers'). Our goal should thus be to minimize the risk for any programmer of making mistakes, encountering hidden bugs based on language pragmatics our interpreter behaviour. Please see this feature request in that light. The most important part for me was item (1) to notify the programmer that he is comparing pointers, when he wants to compare elements. The proposed way may not be acceptable, but I will make a stand that most LDMUD users will not know a pointer if it hit them in the ... |
|
|
Due to the reasons already given in the notes we will not pursue this idea any further. Therefore closing this ticket. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2010-11-07 06:25 | _xtian_ | New Issue | |
| 2010-11-07 06:31 | _xtian_ | Note Added: 0001909 | |
| 2010-11-07 09:05 | zesstra | Project | LDMud => LDMud 3.5 |
| 2011-01-25 15:17 | Gnomi | Note Added: 0001958 | |
| 2011-02-13 21:58 | zesstra | Note Added: 0001968 | |
| 2011-02-14 16:50 | zesstra | Relationship added | related to 0000266 |
| 2011-02-15 12:47 | Sorcerer | Note Added: 0001994 | |
| 2011-02-24 00:37 | Coogan | Note Added: 0002035 | |
| 2011-02-24 11:08 | _xtian_ | Note Added: 0002041 | |
| 2021-04-16 22:09 | Gnomi | Status | new => closed |
| 2021-04-16 22:09 | Gnomi | Resolution | open => won't fix |
| 2021-04-16 22:09 | Gnomi | Note Added: 0002615 |
