Jump to content

Recommended Posts

This is the yellow brick road to unpredictable behaviors depending on the uses list.

Use "TMyStringList", don't try to rewrite the RTL.

Share this post


Link to post
6 hours ago, Dalija Prasnikar said:

 But you can have your own implementation

Can't use the operators that we have in other languages 

Share this post


Link to post
7 hours ago, Dalija Prasnikar said:

If I had a dime for every time I though "this string cannot be nil here, so I don't need to check" and then I had exceptions at runtime, I would be on my tropical island right now, drinking pina colada.

Why would you need an excuse to do that. Go for it anyway!

Share this post


Link to post
50 minutes ago, David Heffernan said:

Can't use the operators that we have in other languages 

True. But that is not the argument for nil string and arrays, on the contrary.

 

I am all for having nullable types built in, together with full language support, but that does not mean I am for changing how strings and arrays work. Nullable types should be wrapper on around those and value types.

Share this post


Link to post
2 minutes ago, Dalija Prasnikar said:

True. But that is not the argument for nil string and arrays, on the contrary.

 

I am all for having nullable types built in, together with full language support, but that does not mean I am for changing how strings and arrays work. Nullable types should be wrapper on around those and value types.

All I said, and you can go check, is that it is sometimes desirable to distinguish null from empty. 

Share this post


Link to post
On 9/24/2021 at 7:17 PM, Uwe Raabe said:

Yes, just like TDateTime = Double... and just like SizeOf(Char) = 1 until a thunder stroke at 2009 🙂 For me, not relying on implementation details is just an additional layer of stability. In 2009 those who weren't assuming Char is almost the same as Byte, could adopt Unicode with almost no changes. Others were suffering. If sometimes TDateTime becomes a record with two numbers (f.ex., days from 1 Jan 0001 and msecs of day), those who write "secsBetween := (dt1 - dt2)*86400" will suffer. Me, using "secsBetween := SecondsBetween(dt1, dt2)" won't.

 

On 9/24/2021 at 8:12 PM, Mike Torrettinni said:

Hm, I use it a lot. I prefer array <> nil over Length(array) > 0.

I personally consider it bad style.

This relies on impl details, and any new coder will have to keep in mind these nuances. "What, var is null here? Okay, I know that from my Java/SQL/JS background. Let's assign it with 0 length for now, to be expanded later. What could go wrong?"

Moreover, sometimes you want to refactor. F.ex., array becomes insufficient and you change type to TList.

Option #1, if using `Length(arr)`: change type, try to build, change all `Length(arr)` to `arr.Count` that compiler will complain on

Option #2, if using `arr = nil`: SUFFER.

 

P.S. Honestly I don't see why array literals took so long to add. Clause "if arr = []" would be pretty obvious and consistent to string type

Edited by Fr0sT.Brutal
  • Like 1
  • Thanks 1

Share this post


Link to post
On 9/25/2021 at 11:57 PM, David Heffernan said:

All I said, and you can go check, is that it is sometimes desirable to distinguish null from empty. 

I agree.  
NULL = There is no list.

Empty = There is a list, but it is empty.

 

Share this post


Link to post
1 hour ago, Fr0sT.Brutal said:

those who write "secsBetween := (dt1 - dt2)*86400" will suffer.

I don't have such example, but I searched in some third party source and there are plenty same and similar examples. I see this is 'never use Magic numbers' more than a 'it's implementation detail that can change'.

 

34 minutes ago, Lars Fosdal said:

NULL = There is no list.

Empty = There is a list, but it is empty.

I would totally understand if arrays follow same logic. And if they ever change that, I will gladly use Length and not nil.

 

I was thinking about this and probably is specific to just me, but I actually find it easier to distinguish between = and <> when using nil vs Length:

if DataArray = nil then ...
if DataArray <> nil then ...
vs
if Length(DataArray) = 0 then ...
if Length(DataArray) <> 0 then ...

Especially if condition is part of longer condition, is just easier to quickly identify what is going on.

Edited by Mike Torrettinni

Share this post


Link to post
1 hour ago, Fr0sT.Brutal said:

Clause "if arr = []" would be pretty obvious and consistent to string type

Fixed it for you:

const
  EmptyArray = nil;

var
  numbers: TArray<Integer>;
begin
  if numbers <> EmptyArray then
    Writeln('not empty');
end.

 

  • Like 1

Share this post


Link to post
8 minutes ago, Stefan Glienke said:

Fixed it for you:

Are you using "if StringVar = EmptyStr" as well?

Share this post


Link to post
2 minutes ago, Fr0sT.Brutal said:

Are you using "if StringVar = EmptyStr" as well?

Nope, depending on the target version I am writing "if StringVar.IsEmpty" 😉

Edited by Stefan Glienke

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×