1

Something that has been boggling my mind is that I don't understand why some (most) string routines are functions that give a result and some string routines are procedures which change the original string.

S2 := Copy(S1,3,2);

Copies into S2 from S1 the 2 characters starting from the 3rd position.

Delete(S,3,2);

Deletes from S the 2 characters starting from the 3rd position.

I would have thought it more consistent to have Delete (and a few others) behave like most other string routines, so you could write: 

S2 := Delete(S1,3,2);

Why isn't that the case?

Rob Kennedy
  • 161,384
  • 21
  • 275
  • 467
Pieter B
  • 1,874
  • 10
  • 22
  • That's by design. And changing this to the same model would break compatibility with the code written in earlier versions. – TLama Sep 20 '13 at 14:07
  • 3
    This isn't really the place to discuss this. Yes those ancient functions are designed inconsistently. We know now that mutability makes programming more complex and error prone, and that a functional style that returns new values is usually preferable. But that doesn't really make a Stack Overflow question. What do you want us to say? "Yes, it would be more consistent the other way." Modern versions of Delphi address this with the string helper. – David Heffernan Sep 20 '13 at 14:08
  • 1
    If you want to `copy` you need S1 to copy from and S2 to copy to. If you use `delete` for what is S2 good for ? when you're done with the delete ( if you want to delete more than one char) : do `S2 := S1;` It's better than ten times `S2:=Delete(S1,x,2);` I think `Borland` have thought about it and willed to do it like it is. – moskito-x Sep 20 '13 at 14:35
  • 2
    I've voted to reopen the question because after my edits, I don't believe it to be primarily opinion-based anymore. It's not asking whether something would be better, just why things are the way they are. I suspect the answer is *just because*, which isn't very interesting or satisfying, but that's no reason to keep the question closed. – Rob Kennedy Sep 20 '13 at 15:48
  • 2
    @Rob, why is that so can answer only someone who designed Delphi in its early ages. Or someone who finds an article of such person. The rest of us can only speculate. I'm keeping this closed for the same reason. – TLama Sep 20 '13 at 16:04
  • IMHO `Delete` would be poorly named if it were implemented as a function. – Disillusioned Sep 20 '13 at 16:25
  • 1
    So what if it's hard to answer, @TLama? Why actively *prevent* people who know the answer from posting it? If people post answers that are just guesses, then let's vote those answers down. There's no need to punish the question for that. – Rob Kennedy Sep 20 '13 at 16:27
  • @moskito-x, `Delete` is so called **mutator method**, while `Copy` is **accessor**. – Free Consulting Sep 20 '13 at 17:56
  • @Rob, that's what the close votes are for. But well, I'll vote to reopen this one, since I'm wondering what will be the answer to why are procedures like `Delete` designed as procedures and not as functions. – TLama Sep 20 '13 at 18:01
  • David: is it really an inconsistence, or is the question biassed due to a viewpoint from an immutable string world? – Marco van de Voort Sep 20 '13 at 19:15
  • 3
    My thought is that this would make a great question of functional design if edited to reflect that, and therefore would be great [here](http://programmers.stackexchange.com/). IMO the discussion would be interesting. – Glenn1234 Sep 20 '13 at 19:43
  • 1
    [Asked here.](http://programmers.stackexchange.com/questions/212124/good-procedure-or-function-design) Hopefully there will be some good discussion that will come out of it. – Glenn1234 Sep 21 '13 at 02:59
  • @Marco There's a reason why immutable strings exist. That approach was not devised by chance. But forgetting immutability for a moment, my other point is that returning new values as function return values is usually preferable to modifying parameters passed by var. The reason is that the former enables composition in expressions. Function return values can be passed into other functions, or used as operands. – David Heffernan Sep 21 '13 at 06:42
  • @David: can be used in functions, but taking a copy is always fundamentally slower. One reason in favor, one against. And I think for rock bottom string primitives as Delete, speed is the more important design principle. Afaik immutable strings mostly to easy copy-on-write semantics, but the point is that is different in Delphi, thus not applies here. – Marco van de Voort Sep 21 '13 at 09:03
  • @MarcovandeVoort It comes down to what drives the design. Performance or programming convenience. – David Heffernan Sep 21 '13 at 09:13
  • @David: I would say, for something in system, performance. For something in sysutils/strutils convenience. But delete() predates those latter units. Probably came in with strings in TP4. – Marco van de Voort Sep 21 '13 at 09:38

2 Answers2

4

The reason is in the name.

Copy is a function because it is supposed to create a copy. A procedure version of Copy would need an additional parameter, because when there is already a source, where would the target go?

Delete is a procedure because it is supposed to delete characters from a string. For a function version of Delete which returns the outcome of the delete operation, what should become of the source? You're calling a delete operation on it: it cannot remain unaltered.

As analogy; compare it with the procedure TRect.Offset and the function TRect.CenterPoint. Offset performs an operation on the entity, where CenterPoint reads a attribute of the entity.

NGLN
  • 43,011
  • 8
  • 105
  • 200
  • "Delete is a procedure because it is supposed to delete characters from a string." But it's also bad computer science. When looking at the procedure, you have no idea that it's changing a passed-in value, effectively making it a function. That's something that shouldn't be done, and thus bad form on the part of the standard library. – alcalde Sep 20 '13 at 21:39
  • TRect.Offset is also very badly designed. You cannot compose it with anything. A function that returns a new value is always more useful. – David Heffernan Sep 21 '13 at 06:43
  • You are correct about the naming. Delete would not be the right name for a function since it is a verb and not a noun. But that doesn't mean that the right choice was made. Design it all again and make it a function, but give it a name that matches. For my tastes, I would never have added it to the library in the first place, even a functional variant. Is it widely used enough to warrant its place? – David Heffernan Sep 21 '13 at 06:48
  • The most common use I've noticed for `Delete` is in functions that return comma-separated-strings (or some other separator). A loop adds string + separator. And as a final step the last separator is deleted. (This is certainly not a time when you want the string copied.) – Disillusioned Sep 21 '13 at 12:31
  • @NGLN you're focusing on the copy example I gave too much. For instance a function like StringReplace(S,Substring,NewString,rfReplaceAll]) could just as easily be a procedure or a function, with the same arguments. Problem is, I always have to make a "mental switch", and often look it up just to be sure. – Pieter B Sep 23 '13 at 14:03
1

First, copy() is not a function. It is an intrinsic.

Second it is job is to copy, while in the case of delete() modifying the current string is an option, it is delete, not copyanddelete.

That difference is important because Delphi doesn't suffer from immutable strings like Java and C#.

Before ansistring, returning functions always added at least one copy, which was noticable on the computers of the day. The ansistring case afaik is only better when inlined.

Marco van de Voort
  • 25,628
  • 5
  • 56
  • 89
  • I agree with you : `it is delete, not copyanddelete`. in my opinion, `deleteandcopy` describes this better. ;-) – moskito-x Sep 20 '13 at 19:44
  • "That difference is important because Delphi doesn't suffer from immutable strings like Java and C#." It will be *blessed* with immutable strings in the nextgen compiler, eventually, from what Marco Cantu's white paper suggested. – alcalde Sep 20 '13 at 21:42
  • I don't see a "why" in here. All I can see is, "it is because it is". What am I missing? – David Heffernan Sep 21 '13 at 06:30
  • @David: Why: avoid copy. Plain and simple. Functional always implies copying. This stems of TP days, but as lowest primitive it is still valid (it is a part of other string routines) – Marco van de Voort Sep 21 '13 at 09:09
  • @Alcade: Whether that is a good thing, that is a matter of opinion. And one that will pull in discussion over Embarcadero/Delphi's roadmap and plans. Sufficient to say that for the pre-XE2 uses of Delphi I think it is a bad thing – Marco van de Voort Sep 21 '13 at 09:10