Rudy Velthuis

Ah, thanks. I had seen something like it before, but when I googled, I found nothing useful. The extra S makes it easier to find too. <g>

Ah, indeed. A construct I use quite often. With complete boolean eval that could crash. But you can avoid such problems: if something <> nil then begin if something.someinstanceaccess then ...

I can't see the full context of the case, but say you have: Result := condition1; ... Result := (functionCall1(x) or functionCall2(y)) and Result; In the above case, you may want to have both functions called, even if functionCall1(x) already returns True (or another function call returns False in a subexpression with and). But even then, you can call the functions separately, put their results in variables and then combine the results later on. You may need one or more extra Boolean variables for the functoin results and a few lines more, but the code flow will be clearer. So complete Boolean evaluation is never really a necessity. Other languages manage without it too. And of course you can do: Result := condition1; ... Result := functionCall1(x) or Result; Result := functionCall2(y) and Result; But finding out whether you should use or or and in the two lines above is a bit hairy, IMO, and can be done wrong (I am still not sure I did it correctly, to get the result I expect). I'd prefer separate functon result variables.

If you have the choice, use a Pascal set, as described by others. If you don't have that luxury (e.g. because your code must be compatible with other languages, e.g. when you are writing a DLL or some such), you can do: const Bit0 = 1 shl 0; // or more meaningful names Bit1 = 1 shl 1; ... Bit7 = 1 shl 7; ... Bits_0_3_7 = Bit0 or Bit3 or Bit7; ... if (Value and Bits_0_3_7) <> 0 then ... // equivalent to "or" if (Value and Bits_0_3_7) = Bits_0_3_7 then ... // equivalent to "and" That is a little less convenient, but compatible with C and how most APIs do this. You should of course give the bits and the combinations more meaningful names.

TBits is in fact a bitset. Works well, but a bit overblown if you can easily use a Pascal set, which is far more lightweight (and faster), especially if you have less than 32 items (bits).

Ok, sometimes (yeah, right, funny) I am dense, but what is SCCE? Source Code Compilable Example?

Yeah, got it now. It is different if Result was already set before.

Does Python run on a stack machine? Anyway, if they can manage to have proper if conditions too (and they do) then I don't see why they have this alternative syntax. I looked and saw that CPython emulates a virtual stack machine.

Ok, I get it now, thanks David and Uwe. You guys mean that if Condition is False, Result will not change. Still, then one can do: Result := Condition or Result; But this assumes that Condition will be checked first, otherwise a possible function call you expect to be made is not made. I think this order is guaranteed, but I would not really count on it. Anyway, the form with the if clause after the assignment doesn't make sense to me.

AFAIK, in Python such a construct is used as some kind of ternary operator: result = 'N' if (property == 'A') else 'Y' I guess they didn't put the condition first because then the interpreter will have a harder time infering the type of result (pseudo-Python): result = if (property == 'A') 'N' else 'Y'; or because there is no nice separation between the condition and the true result.

That is not the same.

In the case given, it has the same meaning. I often see people write something like if condition then Result := True else Result := False; while a reduction like Result := condition; is often not considered.

No, and I am glad about that. having the if after the condition is something I never understood or liked in Python. I mean I understand the construct but I never understood why it was done that way. And I know one must be Dutch to understand some things in Python, but heck, I am Dutch, and have been for the last 58 years (I'm only 4 years younger than Van Rossum). FWIW, the parentheses are not required here: if Condition then Result := True; Or even better: Result := Condition;

ISTM that it simply doesn't make a lot of sense to guess the decimal separator. In some scenarios it might work, but not in others. We humans can sometimes extract such information from the context, but you'd need better AI for that.

MMX doesn't define the language. And records can only have static class methods anyway.

This is parsing strings. You can't tell if a string contains an integer until you parsed it. And integers could contain one single thousands separator. Say we have `100,001`. Is that the floating point value 1.00001e+03, the integer value 100001, or the floating point value 1.00001e+00? Hard to tell, IMO, if you don't know if the dot is a decimal or thousands separator.

Actually, High(x) is not always implemented as Pred(Length(x)). In routines with open array parameters, Length(x) is actually implemented as Succ(High(x)), because the High value is passed, not the Length value. But you are right about checking for nil and caching the value.

And records have class constructors and class destructors too. You seem to be confusing class destructors with destructors. Records cannot have destructors, but they can have class destructors. These are not the same thing. See the link I posted in another reply.

That feature (managed records, i.e. records with default constructors, copy constructors, conversion constructors, overloaded assigment operators and destructors) was postponed, actually. Currently, records cannot have destructors, not even in Rio. But I was talking about class destructors, not the normal instance destructors. Records cannot have destructors (yet), but they can have class destructors, even in much older versions (IIRC, since XE2, but I may be wrong about the version).

A record type can have a class destructor too. A record type just can't have a normal destructor yet.

You meant " The angle rounded to whole degrees for which a rainbow appears (the critical angle). ", right? 🌈🦄

Why? We are talking about Delphi, and I am of course assuming that, whatever it is that takes the boring and tedious and often failing manual tasks off my hands, works. Nothing is safe if it doesn't, not even a memory manager for manual management. (Sheesh!)

Yes, that may be. I actually declare parameters as the type that is needed, and not everything as string.

There are other things that are not fine for operators. One of the parameters or the return value must be of the type of record; there can only be one or two parameters, depending on the operator; etc. So they are not just normal functions. As I said, IMO it is against the notion of using operators to have open array parameters, i.e. against the semantics, not necessarily against the technical possibilities. As I said, I can't really put my finger on it yet, but it simply feels wrong. Not everything that compiles (i.e. that the compiler allows) is the right thing to do. > And surely you understand why operators are often preferred to functions. Sure. That doesn't mean they are the best thing to use in all circumstances.

First: I don't "allow" anything. But I think it doesn't make sense, in Delphi. As I said, it is possible with templates, because these can have value parameters like std::size_t N too. But that would still preclude dynamic arrays too, or their C++ equivalents. I do notice that that creates TWO overloaded operators: one for single-element static arrays, and one for two-element static arrays. In other words, it has two types. In Delphi, you can do that too, with overloading, but then you would have to create a type and an overload for every size. In other words: in Delphi, that doesn't make sense. Yes, it would be nice in your simple example, but if you have an open array parameter, it must accept dynarrays as well as static arrays of any size, and it must accept open array constructors (like a function Func([7, 8 9])). How would you do that, syntactically? Just like it doesn't make sense to give a dyadic operator like = or / a third operand, an open array constructor doesn't make sense either. A dynamic array is different. It is a single item, a single type. You could also have a single statci array type. Or several. See above. Can you explain why you can't use a function?