Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation on 08/26/24 in Posts

  1. New blog post on WITH statements. The topic was recently discussed once again in the Delphi Developers Telegram group which triggered a blog post: https://ideasawakened.com/post/why-you-should-not-use-WITH-in-your-Delphi-code
  2. Lajos Juhász

    "Death to WITH" in your Delphi Code

    There is no need for with in your example: procedure TMyForm.UpdateInventoryItem(const NewQty: Integer); var a: <the required type>; b: <the required type>; begin a:= dmStoreInventoryData; b:= A.tblUpdateItemForStore; B.Edit; B.FieldByName('Qty').AsInteger := NewQty; B.Post; end; With will not make this code any cleaner.
  3. Darian Miller

    "Death to WITH" in your Delphi Code

    My guess is that Aliasing would bring in a new set of problems but if it's just a preprocessor type replacement, it might be OK. But look at your example code - what is the scope of "NewQty"? Does it belong to A, to B, or to the Form, or to a variable or method somewhere? If it doesn't belong to A or B, what if "NewQty" is added to A or B as a property or method later? Boom, your with-bomb will explode into a nice bug.
  4. Brian Evans

    "Death to WITH" in your Delphi Code

    If they added the ability to provide an alias the ambiguity would be gone. Aliases in SQL are useful and perform a similar function. Shortening repeated references can make code easier to read, the problem is the current WITH creates ambiguity. A code snipped from the blog post redone with the ability to provide an alias as an example: procedure TMyForm.UpdateInventoryItem(const NewQty: Integer); begin with dmStoreInventoryData as A do begin with A.tblUpdateItemForStore as B do begin B.Edit; B.FieldByName('Qty').AsInteger := NewQty; B.Post; end; end; end;
  5. Dalija Prasnikar

    ifthen strange return value !

    It doesn't work like that. LObj is reference type. That means it consists of two parts. LObj variable itself is merely a pointer (address) that will point to the object instance when it is allocated on a heap. All local variables are allocated on stack, not heap. So when you declare local variable the memory for the pointer is automatically allocated on stack when FormCreate is called. Stack memory is not automatically cleared, so whatever values were there, they will remain. Only managed types local variables will be automatically initialized. When you create object and assign it to that variable then created instance will be allocated on a heap and address of that memory location will be stored in LObj variable. This behavior is same on all platforms. However, until Delphi 10.4 Delphi mobile platforms had ARC compiler where objects were automatically managed and local object variables were automatically initialized on those platforms.
  6. Spook

    SpkToolbar for Delphi

    Hi there, I happen to be the original author of TSpkToolbar (Spk = Spook). The fun fact is that it actually was designed for Delphi in the first place (now-ancient Delphi 2006). It is absolutely amazing, that my control still lives for all those years after I decided to opensource it and donate to the Lazarus community. Also, thanks for contributing 🙂 I'm long past my Delphi days, but I always think about Delphi community warmly and I'm happy it is still thriving 🙂 Best regards -- Wojciech "Spook" Sura.
  7. Brian Evans

    "Death to WITH" in your Delphi Code

    Introducing new variables isn't the same as WITH which just adjusts how the compiler handles scoping for which reference a name refers to at compile time. If introducing a new variable isn't an issue may as well use inline variables with type inference for modern Delphi at least. procedure TMyForm.UpdateInventoryItem(const NewQty: Integer); begin var A := dmStoreInventoryData; var B := A.tblUpdateItemForStore; B.Edit; B.FieldByName('Qty').AsInteger := NewQty; B.Post; end;
×