Lars Fosdal

https://firebase.google.com/docs/reference/rest/database

I wish the "class abstract" declaration would have prevented .Create instantiation.

https://cloud.google.com/datastore/pricing

I prefer my PS shells to be native. There is so much functionality that can be lost otherwise.

Is this a known issue? If you assign an anonymous function to a property, there is no warning if the result of the function is not defined. Normally, a function where Result is not set will yield a warning. program anon_method_func_result; {$APPTYPE CONSOLE} {$R *.res} uses System.SysUtils; type TConvertFunc<T> = reference to function(const invalue: string; out outvalue: T): Boolean; TValue<T> = class private FConverter: TConvertFunc<T>; public property Converter: TConvertFunc<T> read FConverter write FConverter; constructor Create; end; constructor TValue<T>.Create; begin FConverter := function(const inValue: string; out outvalue: T): Boolean begin outvalue := Default(T); // Would have expected a warning here // since Result is never set end; end; begin try try var V := TValue<Integer>.Create; V.Free; except on E: Exception do Writeln(E.ClassName, ': ', E.Message); end; finally {$ifdef Debug} Write('Press Enter: '); Readln; {$endif} end; end.

It exists to balance out my inherent sense of imminent doom.

If a user has modified the behaviour or installed an app that causes the "open" verb to behave differently than the default behaviour - that is a user problem, IMO. If you want to open a .pdf file, "open" is the way to go.

I prefer regulation over learning that my debt has increased 500% the last week.

If the parent process runs at a higher security level than your own, you will have a hard time gleaning info from the process without elevating your own process. Since CreateProcess explicitly can specify a different working directory than the current (i.e. the parent) - there is no bullet-proof way of knowing the actual working directory of the parent process.

It is hard to have stability without regulation. Ref. crypto volatility.

Looks like you are describing a mix of public key encryption (PKE) and access control. PKE only has one encryption key and a one decryption key. Would it not be easier if Harry simply has both keys - one for the driving license and one for the passport? That would mean - one document, one encryption key, and one decryption key, with a list of people that has access to the decryption key for each document. Or - you could turn that around - one encryption key, one decryption key for each document owner and a list of people who has access to which documents (the documents share the same decryption key).

One great benefit of switching to a regulated digital currency is that it will make corruption more difficult.

I haven't seen any of that. There are rules here which govern how the APIs can used. I am not 100% certain, but it seems the APIs can only be accessed in the user's context, so the "other" bank doesn't actually "see" the numbers.

Circular references create a lot of fun.

So, you want openness to go only in your favor? 😉

Open banking is no joke - although I think the interpretation of the term varies with the country you are in. Among other things, open banking allows the banks to hook into each other's APIs so that I, as a client of bank 1 and bank 2, open my page in the UI of bank 1, I can also see the account balances from my account(s) in bank 2. Typically, banking fees are fairly low here and there is no surcharge for this cross bank service.

A generic class constructor can behave even weirder. https://docwiki.embarcadero.com/RADStudio/Sydney/en/Methods_(Delphi)#Class_Constructors

FinTech is an abused word.

Whenever I write console test app, I am annoyed that I must change from program Project2; {$APPTYPE CONSOLE} {$R *.res} uses System.SysUtils; begin try { TODO -oUser -cConsole Main : Insert code here } except on E: Exception do Writeln(E.ClassName, ': ', E.Message); end; end. to program Project2; {$APPTYPE CONSOLE} {$R *.res} uses System.SysUtils; begin try try except on E: Exception do Writeln(E.ClassName, ': ', E.Message); end; finally {$ifdef Debug} Write('Press Enter: '); Readln; {$endif} end; end. which is what I normally want. Is there a way to replace the default code template for a new console project? I would have expected to find it under Tools | Template Libraries - but there is no console project there.

It's been a while since I tried doing generic based controls, but I think I ran into the same issues. In the end, I changed my approach to using proxy classes that simply hook into the control at runtime and take over its events.

It is true that if the generic code does not need to touch methods from the interface, the generic type constraint<T:sometype> can be eliminated, but who am I to say what @luebbe will put in his interfaces and code?.

Would methods exposed by IMyIntf be visible for references to T in the generic code without that constraint?

It takes a bit of practice - as all things. Me - I struggle with interfaces since I rarely use them.

The trick to generics is to only specify the desired type on the left side of a declaration and use <T> to "pass it on". Something like this.. type IMyIntf = interface; TMyList<T: IMyIntf> = class; TOnListItemSelected<T:IMyIntf> = procedure(AItem: T) of object; TOnListUpdated<T:IMyIntf> = procedure(AList: TMyList<T>) of object; IMyIntf = interface ['{FCAFF2E8-5F8E-4473-8795-89BD41C89D57}'] end; TMyList<T: IMyIntf> = class FItems: TList<T>; FOnListUpdated: TOnListUpdated<T>; procedure ListUpdated; end; { TMyList<T> } procedure TMyList<T>.ListUpdated; begin if Assigned(FOnListUpdated) then FOnListUpdated(Self); end;

/facepalm