Leaderboard

It's not about proper naming - its about newly added members creeping into the with scope - as happened when TRect got Height and Width properties! It was perfectly clear that Top, Left, Right, Bottom referred inside the with belonged to the "withed" rect variable and Height and Width to something outside - now those got added to TRect and boom.

We are talking about TRect here. Very basic type used all over. It is not very likely that one will create his own types for just about everything. And this is where using with can easily break your code without you even realizing it is broken. This is especially problematic when used in combination with UI where testing is hard and you can have a lot of code that is poorly covered with tests that could reveal such issues. 'with' is relic of another time and another coding practices. And, yes you could shoot yourself in the foot even back then, but now it is extremely easy to do so. Not using 'with' is the best advice one could offer. It is almost like using goto and absolute. You may have some very limited use case where using it is justified, but you will not find such constructs being used at large.

Guess what - there are even rules that will tell you when you access things without using this in static code analyzers - and there are good reasons to do so (although I personally dislike it) Speaking of programming language design - you never can make everything perfect and there are always features that have some "be careful with it!" tags on them. However features that are so often accused of causing problems or confusions can be declared bad. And yes, every language has them and every responsible Developer should know when it safe to use them. Fun fact: I just recently consciously used goto because it yielded a noticable performance gain and rewriting the code without it would have been a massive undertaking resulting in more complicated code than just putting a goto there. And no, no raptor attacked me (yet...)

I beg to differ. Naming a property/function more explicitly for the sake of with is...how do I put this politely?...not helpful. Say I have a class TCar with properties Wheel and Engine and functions Drive and Park. If I understand you correctly you would expect me to call those properties and functions CarWheel, CarEngine, CarDrive and CarPark, to be explicit enough for the rare case when someone uses with on my TCar...

Using "with" can clean up the code to make it easier to read, but ever since the dawn of Delphi, it had a severe downside that "with" hinders debugging. You can't simply hover with the mouse cursor over a variable to get its value or use evaluate/modify on the variable itself without having to copy & paste the record/class name first. And now I've encountered a more recent issue with refactoring. If you use refactoring to rename a variable inside a record, it will miss any instances where the record was used with a "with" statement. Will this ever be improved? If not, what are your recommendations?

What is sure with "with" discussion is that it is a trolling subject in the Delphi community since decade(s). For instance, the topic is about "with" in general, and that @Yaron stated that the IDE debugger has troubles with it. TRect came as a true problem about "with" - I do agree with Stefan. But problem came from Embarcadero, not taking into account existing code base. Just like ARC, or the AnsiStrings... Most dev people outside this forum would argue, paraphrasing @Dalija Prasnikar, that 'Delphi is a relic of another time and another coding practices: for instance, there is no GC !'. Php adepts would argue that writing $this->foo is much cleaner/safer than what Delphi (and other languages) do about properties. I like "with" - when properly used for two-liners code - as I wrote. It is a clean way of writing code, "making it easier to read" as wrote Yaron. Similarly, I like "object" more than "record with methods", since it allows easy inheritance - when using high-performance code with pointers and pre-allocated memory buffers/arrays. Of course, with only static methods. This was just my 2 cents, to introduce another POV into the discussion. Nothing is totally black nor white.

Breaking compatibility by adding properties is very likely to break code... My assumption is that you use and maintain your own classes. This was not my point. I didn't mean CarWheel for sure. Wheel, Engine and Drive are fine. a, b and x aren't. And I wouldn't use "with" over two TCar instances, or two classes with a Wheel property. But it would have sense, say e.g. to write something like: with currentCar do CarInfo.Caption := format('Engine %s with %d wheel(s)', [Engine.ModelName, Wheel.Count]); My point was that "As everything powerful can be armful when misused, I like "with", when it is not over-abused". If the "with" scope is small enough to be obvious and safe, fine. Otherwise, use local variables.

And the most reliable way to concentrate on creating the best product with a "no need to learn how to use" UI.

As everything powerful can be armful when misused, I like "with", when it is not over-abused. For instance, I like "with", when it has only several lines of scopes. It does make sense to me, when used for a single line. Otherwise, I switch to an implicit local variable: asm generation would be the very same. If you think "with" should be avoided due to its implicit context switch, I guess next step would be to force using self.foo for class properties... just like the $this->foo of Php... what a progress! 🙂 I am against any new warning at compiler level. And if you are confused by with someclass do x := a * b and don't know to which class a, b, or x belongs to, it is time renaming the properties/functions to something more explicit!

The most reliable way to avoid the legion of bugs with this feature

Regarding a fix, this is only one of a number of problems with scope resolution in the language. Same issue arises when you use units, where more recently imported symbols hide those from units imported earlier. Same for local variables and methods. Same for local variables and global symbols. Anywhere where you refer to a symbol and there are multiple matches then the compiler chooses the most recent. In princple the resolution is simple. Introduce a new compiler warning whenever the compiler uses this most recent principle.