Mason Wheeler :

…which can be done just as easily with IFDEFs, which has the further advantage of making your intentions explicit.

I’m not a fan of IFDEFs, since they mingle optional or platform-specific code with regular code, they are often a PITA to deal with in greater code-bases, and you need to run multiple builds with all the various IFDEF conditionals to check everything.

If you composite with partial classes, then you get compile-time checks with a single-build, and you can segregate optional functionality to optional files in a much cleaner way than using IFDEF/INCLUDES (especially since with IFDEF/INCLUDES, you would need one file for the declaration, another for the implementation, like in C).

For instance in Delphi that means you could have optional LiveBinding capability for components, without having forced LiveBinding dependencies even if you don’t need them.

As for dynamic/RTTI description, I’m of two minds there: on one side having a separate DFM/XML is convenient, on the other, it means you end up with RTTI and runtime errors, where you could have had static typing and compile time errors, ie. the flexibility you get comes at a stability price. And refactoring code with compiler support is simple, refactoring resources DFM/XML isn’t.

Enables separation of a class’s interface and implementation code in a unique way.

Good point, this one was copy-pasted and is irrelevant to Pascal, I’ll scratch it from the list.

And wouldn’t a class big enough to be broken up this way violate SRP anyway?

Sometimes, classes just have to be big to be practical IME (of course that shouldn’t be abused), or you end up with overcomplicated architectures or “public everything”.
Think of TComponent, and other base classes that introduce support for multiple interfaces.

Partial classes can turn especially useful for interfaces, as you can segregate the interface declaration & implementation in another, optional unit.

…huh? How do you make navigation easier by giving it more files to lookup and keep track of?

By making the file focused on one aspect, f.i. if you use the partial class to implement an IPrintable interface, or an IDragDropAble, etc. You’ll have a bunch of related methods that extend the class, and are intrinsically optional, and exchangeable.

F.i. even if you don’t like the Delphi LiveBinding implementation, you’ll have to deal with it, or at least carry it around as RTTI dead weight. If it had been made into a partial class, you could have avoided it if you were not using it, or replaced it with some different design/implementation.

> Facilitates the implementation of code generators that have to “inject” code declarations/implementations that comes form other descriptions, such as a Visual UI designer, data and string resources, etc.

Yeah, this is why .NET has partial classes. Instead of using a form-definition language like Delphi, they added all sorts of unnecessary complications and difficulties to Winforms by doing the whole thing in code. (I can’t help but wonder if part of the motivation for XAML didn’t come from them finally realizing what we had known all along: that that’s a horrible way to set up forms.)

> Enables separation of concerns, in a way similar to aspect-oriented programming but without using any extra tools.

If you’re trying to separate concerns, why are you putting them together in the same class?

> Enables optionally composited functionality, which can be omitted or substituted depending on target or requirements..

…which can be done just as easily with IFDEFs, which has the further advantage of making your intentions explicit.

> Enables separation of a class’s interface and implementation code in a unique way.

“Unique” unless you mean “the same as how C and C++ do it,” which is a horrible model. There’s a good reason why .h files don’t show up in other languages.

> Enables multiple developers to work on a single class concurrently without the need to merge individual code into one file at a later time.

Enables multiple developers to develop parts of a class independently, with no coordination, so you end up with a mess of a class whose parts don’t work together well. (And wouldn’t a class big enough to be broken up this way violate SRP anyway?)

>Eases navigation through large classes within a editor.

…huh? How do you make navigation easier by giving it more files to lookup and keep track of?

Stefan Glienke :
Wow! I wonder when you will add full AOP support to DWS

Partial classes were a low-hanging fruit, actually, at some point all class were partial “courtesy” of a compiler bug
That said, before AOP, there are attributes, generalized “set of” & templates in the pipe, along with probably a myriad of loose bits, ends, and minor features!

As a part time C++ hack, the var modifier seems redundant. As you say, you are bound to interpret
procedure IncMe;
as non-const; what does marking it explicitly so bring to the party?

And if you lessen the “const” with assignable constants and allow mutating methods, then you might as well drop the “const” keyword from the language, and use “var” everywhere, because that’s what you end up with…

The language does support constants and immutability, and the compiler does take advantage of it for optimization… except when “records with methods” where introduced, they essentially broke that, and some of the optimizations the compiler *still* does with “const” are essentially invalid.

The current situation is either a combination of oversights when adding features to the language or compiler bugs: you can’t have both the compiler optimize for “const” and have “const” be treated as “var” at the same time…
Some parts of the compiler still properly honor “const”, others don’t.

I don’t think it’s a desirable situation, as basically, you’ve got a half-supported language feature, where you could have a tool to leverage better code quality, and better compiler optimizations.

By defining
const Olaf: TPerson =(Name : ‘Olaf’; Age : 43);

“Olaf” becomes a constant as expected, which means that Olaf := Daniel would not compile as expected.
Olaf.Age := 42 would still perfectly be fine – unless you defined “Age” as constant as well.

In other words “const” never has a meaning for the contents of a container. It only influences the container. This means it is completely up to you, the developer, to decide how a method in a record would work. I would definitely object making “const” somehow influence a method’s behavior.

If you look at Objective-C for example. then you will notice that immutable types wouldn’t expose any “set-like” methods at all, but have constructors for initializing values only – obviously for a reason. This is of course not really a language feature, but more a framework feature.

Regards,
Olaf