Feature request: automatic correct method implementation / definition

Elements Oxygene
1

If I have the following code:

type MyType = class
public
  method MyMethod(param: String;);
end;

implementation
method MyType.MyMethod(param: String);
begin
end;

If I change the implementation to

method MyType.MyMethod(param: String; param2: String);

Then I have to change the definition by hand.

Request: automatic update the definition with Ctrl-Shift-C when there are no overloads.

1 Like
2

Q: How would the feature know which of the implementation or the interface signatures are the correct one ?

Possible answers:

  1. By examining the edit history to determine the most recently modified and assume this is the correct one.
  2. Always assume interface is correct.
  3. Always assume implementation is correct.
  4. Only correct the counterpart of any signature under the edit caret.
  5. If the edit caret is in the interface section, assume interface signatures are correct (and vice versa if the edit caret is in the implementation).
  6. Reverse of the above - assume that the edit caret is in the section that you wish to be corrected.
  7. Don’t have separate interface/implementation sections. :slight_smile:
  8. Rather than over-loading the class completion utility, provide this as a specific, separate “Ensure signatures match this one” (or other named) refactoring that operates on the syntactic element in context.
  9. … ?

Possible problems with above approaches:

  1. You may have edited the implementation signature and then realised that your edit was not needed and wished to revert to the interface signature. Yes, you could/should simply undo, but perhaps that signature change is not the most recent change in the undo history.

  2. If you are working intensely in the implementation area and change your signature there without first/subsequently updating the interface then the next time you use Ctrl+Shift+C any implementation signature changes will be reverted to the interface signatures.

  3. Similar but reverse of problem with #2.

  4. This doesn’t help to bring multiple signatures into consistency, where multiple signatures have been modified and overloads a special refactoring of a selected syntactic element onto Ctr+Shift+C which otherwise is a more general completion utility that operates at a much broader scope.

  5. This could work, but could lead to frustrating consequences if the edit caret isn’t where you need it to be at the point that you might wish to invoke the utility. i.e. after changing a signature, attempting to compile, navigating to a syntax error arising from a mis-matched syntax - the edit caret will be in the position that you wish to be corrected rather than the one that specifies the correct signature. Invoking the utility at this point will have the opposite of the intended effect. Yep, a quick jump to declaration before invoking completion is all that’s required, but still.

  6. Solves problem #5 but is deeply counter-intuitive.

  7. Separate sections can be beneficial when dealing with larger/more complex classes.

  8. Um… a winner ? :slight_smile:

3

For me it is 5.

4

Another solution: synchronized editing.

1 Like
5

MMX on Delphi uses 5.

6

7 :smiley:

1 Like
7

The place where you press Ctrl-Shift-C is the place where it is correct.

8

For those who “voted” 5… If I have removed a method in the implementation section and Ctrl+Shift+C now acts to correct the interface section, that method declaration should be removed from the interface ?

If I have removed a method declaration from the interface and press Ctrl+Shift+C, the corresponding implementation should be removed ?

Or this new corrective behaviour of class completion should only apply to method signatures ? What about method names ? Return types ?

Sorry, but this still sounds and feels like a new and separate type of correction refactoring which should not be conflated with class completion.

9

All of them: Yes.

10

Yeah, I see none of this as satisfactory solutions. Update both signs manually, or (better) use unified class syntax, I’d say.

11

Unified class syntax: you mean like c#?
If so - then I lose the clear type definition - where you can see the complete class structure.
For me, this is one of the best things of Pascal.

3 Likes
12

Fair enough, that’s why we keep the old syntax as an option.

13

I use a mix: For small, simple classes, unified syntax is perfect. For larger, more complex classes, separate interface and implementation, but with some use of unified syntax for the shorter, lightweight methods (you don’t have to choose either/or - you can use both!).

But, every time I find myself reaching for separation of interface and implementation I take this as a red flag that my class may be too large/complicated and look for possible separation of concerns. Not that it’s always possible/relevant. Sometimes classes simply do reach a point where that separation of interface and implementation is useful.

1 Like
14

All of them: Yes

And there’s the problem. It is trivial to devise scenarios where conflating completion with correction will cause more headaches than cure.

1 Like