Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Blaise – A modern self-hosting zero-legacy Object Pascal compiler targeting QBE

github.com

Post reply on HN
Print view View original

11–20 of 59 posts

Re: Blaise – A modern self-hosting zero-legacy Object Pascal compiler targeting QBE

#12

Post by ausare »

“ The Object Pascal ecosystem has two options: Embarcadero Delphi (proprietary, Windows-first) and Free Pascal…”

This part isn’t true, for many years now we’ve also had Oxygene - https://www.remobjects.com/elements/oxygene/ (also proprietary)

Re: Blaise – A modern self-hosting zero-legacy Object Pascal compiler targeting QBE

#14

Post by pjmlp »

ausare wrote: post #12

“ The Object Pascal ecosystem has two options: Embarcadero Delphi (proprietary, Windows-first) and Free Pascal…” This part isn’t true, for many years now we’ve also had Oxygene - https://www.remobjects.com/elements/oxygene/ (also proprietary)

Which has had a strange relationship with Delphi, for a while they were responsible for Delphi.NET.

Re: Blaise – A modern self-hosting zero-legacy Object Pascal compiler targeting QBE

#16

Post by vintagedave »

magicalhippo wrote: post #10
vintagedave wrote: post #8

Earlier quoted context omitted.

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 cod…

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.

Re: Blaise – A modern self-hosting zero-legacy Object Pascal compiler targeting QBE

#17

Post by magicalhippo »

vintagedave wrote: post #16
magicalhippo wrote: post #10

Earlier quoted context omitted.

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 impli…

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.

Re: Blaise – A modern self-hosting zero-legacy Object Pascal compiler targeting QBE

#18

Post by vintagedave »

pjmlp wrote: post #15
HexDecOctBin wrote: post #11

Does this support declaring variables anywhere (as opposed to only in the beginning of a function)? That was my primary complaint when using Lazarus.

Delphi has allowed this for quite some time.

Yes - OP, you can do this via inline vars and consts:

  begin
    var foo : string := 'hello';
    const c : integer = 5;
    var bar := GetBar(); // type inference even
    
    // and in blocks:
    for var i := low(x) to high(x) do...
  end;

Re: Blaise – A modern self-hosting zero-legacy Object Pascal compiler targeting QBE

#19

Post by vintagedave »

magicalhippo wrote: post #17
vintagedave wrote: post #16

Earlier quoted context omitted.

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 impli…

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.

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?

Post reply on HN