5 ms·

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

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?

vintagedave 6mo ago
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.
- magicalhippo 6mo ago
  But you don't need to specify a GUID for an interface in Delphi, and Blaise uses ARC for both objects and interfaces.
  - vintagedave 6mo ago
    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.
    - magicalhippo 6mo ago
      Being restricted to COM-style interfaces, so no true properties like you say, that I totally get. However my question was mostly with the objection against having a GUID, and how Supports() is solved without said GUID, especially since Delphi interfaces doesn't require a GUID in the first place.
      - vintagedave 6mo ago
        I guess the language implementer needs to answer how they implement Supports :) But within one app, ie not crossing boundaries, perhaps their object model's vtable carries references to the interfaces, so casting of any sort to/from object-interface and interface-to-interface would work, including Supports?
- graemeg 6mo ago
  And FPC also supports interfaces without GUIDs via the {$interfaces CORBA} directive, and it too, supports the Supports(...) construct just fine. Delphi is just very Windows-centric with a lot of things they do.
jasim 6mo ago
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.
- rob74 6mo ago
  Not the parent commenter, but what Delphi always excelled at was being able to quickly click together a GUI (with a WYSIWYG UI designer) and easily hook up the events (onClick etc.) to your code. That, and the blazing fast compilation speed which contributed to making quick iteration easy. Think VB6, just with a "serious" compiled language sitting behind it. Current versions of Delphi also support MacOS, iOS, Android and Linux (?), although I'm not sure how well that works, as I got off the Delphi train back in 2010.
  - cestith 6mo ago
    FreePascal and Lazarus certainly support Linux fully, if there are any deficiencies in Delphi’s support.
- magicalhippo 6mo ago
  To be fair, Delphi was left to rot during a crucial point in time, around when .Net was being created. It has struggled ever since due to that. And while the attention to backwards compatibility has been astounding, the move to Unicode-by-default strings was a non-issue for most unlike say Python, the language suffers and feels a bit tedious at times compared to say modern C#. That said, for creating Win32 applications, especially CRUD stuff, there's nothing quite like it in terms of the efficiency of getting deliverables to customers.
graemeg 6mo ago
It's magic! ;-) Not wanting to go into too much technical details: Blaise's interface system uses TypeInfo pointers as identity tokens. Meaning manually added GUIDs are not needed. The two Supports() forms. Delphi has two overloads: // 1. Boolean test function Supports(AObject: TObject; const IID: TGUID): Boolean; // 2. Combined test + assignment (the useful one) function Supports(AObject: TObject; const IID: TGUID; out Intf): Boolean; In Blaise, without GUIDs, the second argument is an interface type identifier rather than a GUID. The most natural design is to treat Supports as a compiler intrinsic (like is/as) rather than a library function, because the second argument isn't a runtime value — it names a type. So Blaise code looks like this: if Supports(Obj, IFoo) then ... // boolean test if Supports(Obj, IFoo, FooRef) then ... // test + assign fat pointer
- magicalhippo 6mo ago
  Ok, so not unlike the RTTI helpers in Delphi then. Consuming a precompiled binary like a third-party DLL is out of scope then presumably, since TypeInfo pointers won't match. Which is fair enough, it's not that common these days beyond actual COM usage. But still not sure exactly why no GUID is a selling point. It's just a bit of metadata.

vintagedave 6mo ago

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.

magicalhippo 6mo ago
But you don't need to specify a GUID for an interface in Delphi, and Blaise uses ARC for both objects and interfaces.
- vintagedave 6mo ago
  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.
  - magicalhippo 6mo ago
    Being restricted to COM-style interfaces, so no true properties like you say, that I totally get. However my question was mostly with the objection against having a GUID, and how Supports() is solved without said GUID, especially since Delphi interfaces doesn't require a GUID in the first place.
    - vintagedave 6mo ago
      I guess the language implementer needs to answer how they implement Supports :) But within one app, ie not crossing boundaries, perhaps their object model's vtable carries references to the interfaces, so casting of any sort to/from object-interface and interface-to-interface would work, including Supports?
graemeg 6mo ago
And FPC also supports interfaces without GUIDs via the {$interfaces CORBA} directive, and it too, supports the Supports(...) construct just fine. Delphi is just very Windows-centric with a lot of things they do.

jasim 6mo ago

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.

rob74 6mo ago
Not the parent commenter, but what Delphi always excelled at was being able to quickly click together a GUI (with a WYSIWYG UI designer) and easily hook up the events (onClick etc.) to your code. That, and the blazing fast compilation speed which contributed to making quick iteration easy. Think VB6, just with a "serious" compiled language sitting behind it. Current versions of Delphi also support MacOS, iOS, Android and Linux (?), although I'm not sure how well that works, as I got off the Delphi train back in 2010.
- cestith 6mo ago
  FreePascal and Lazarus certainly support Linux fully, if there are any deficiencies in Delphi’s support.
magicalhippo 6mo ago
To be fair, Delphi was left to rot during a crucial point in time, around when .Net was being created. It has struggled ever since due to that. And while the attention to backwards compatibility has been astounding, the move to Unicode-by-default strings was a non-issue for most unlike say Python, the language suffers and feels a bit tedious at times compared to say modern C#. That said, for creating Win32 applications, especially CRUD stuff, there's nothing quite like it in terms of the efficiency of getting deliverables to customers.

graemeg 6mo ago

It's magic! ;-) Not wanting to go into too much technical details: Blaise's interface system uses TypeInfo pointers as identity tokens. Meaning manually added GUIDs are not needed. The two Supports() forms. Delphi has two overloads: // 1. Boolean test function Supports(AObject: TObject; const IID: TGUID): Boolean; // 2. Combined test + assignment (the useful one) function Supports(AObject: TObject; const IID: TGUID; out Intf): Boolean; In Blaise, without GUIDs, the second argument is an interface type identifier rather than a GUID. The most natural design is to treat Supports as a compiler intrinsic (like is/as) rather than a library function, because the second argument isn't a runtime value — it names a type. So Blaise code looks like this: if Supports(Obj, IFoo) then ... // boolean test if Supports(Obj, IFoo, FooRef) then ... // test + assign fat pointer

magicalhippo 6mo ago
Ok, so not unlike the RTTI helpers in Delphi then. Consuming a precompiled binary like a third-party DLL is out of scope then presumably, since TypeInfo pointers won't match. Which is fair enough, it's not that common these days beyond actual COM usage. But still not sure exactly why no GUID is a selling point. It's just a bit of metadata.