Comment by magicalhippo
5 hours ago
Looks interesting. As someone who's been using Pascal since Turbo Pascal 6, and use Delphi daily at work, I'm not sure I quite get the "COM-style interface GUID" objection. What exactly about it is complex, and how do you implement Supports() without it?
Not the OP, but I can answer with an objection to COM-style GUIDs myself. Delphi's interfaces are heavily based around COM, and so you need GUIDs, ARC, etc.
But interfaces as a concept don't require the COM backend. If you want your code to be cleanly separated, but don't want to split ownership/management models* (create/free vs ARC), and have no need for an interface and type identity to be managed outside your code and process (ie no COM), then interfaces that are not tied to ARC, and not tied to COM, give the clean code benefit without the baggage.
[*] People work around this by implementing interfaces from a base class with no-op AddRef/Release methods. But this kinda shows the problem: why is that necessary?
I work with Oxygene which is another modern Pascal -- quite a few new Pascals have popped up recently, I get the sense there's a real desire for something new! Our interfaces can be 'clean' and we support soft interfaces, too.
But you don't need to specify a GUID for an interface in Delphi, and Blaise uses ARC for both objects and interfaces.
True! But here at least Blaise is consistent. It’s not mixing models.
My real wish for Pascal interfaces is that they are pure. Some of that is not bringing in COM stuff (including recounting) because I think memory management is or should be different to interface-based clean coding. Another: In Delphi if you define a property in an interface, you have to bring in the getter and setter too. And that makes them implicitly public / visible (even if the implementing class declares them as private.) And they must be methods, there’s no way to say “read, but I don’t care how” (where Delphi can normally read fields too.) In other words, the semantic of “I want a property with read access” causes the interface contract to define the implementation, including making public the normally private / internal backing.
Whereas what I really want is to declare “property Foo: Integer read;” and the interface requires that is satisfied, but not how. In other words, interfaces are pure - they don’t bring in extra baggage. You can do that in Oxygene.
2 replies →
In my early programming days, working with Clipper, I used to look at Delphi from a distance with awe and a bit of jealousy. There also used to be PowerBuilder and Paradox, as competition to the xBase platforms.
I'd love to hear more about how you're using Delphi and what it excels at, compared to current web and native software stacks.