Working on a little project to see how far I can go with it. Always wanted to do something like this, so giving a go. More info coming...

{"name":"gpide001.jpg","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/c\/c\/ccdbb3019f79a00db5c949372dcc8e3c.jpg","w":942,"h":766,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/c\/c\/ccdbb3019f79a00db5c949372dcc8e3c"}

Short Video

I adopted this style almost 20 years ago. It's what I call Object/Method or Class/Method case or whatever. You can only export routines from standard DLLs in Delphi (there are package libraries (BPL), but that's a story for another day), so you must flatten your objects, most of the functionality is in the form of classes, for example, TVideo.Load() the direct representation of this on the front end will be Video_Load. Video_Create will return the TVideo class, and Class_Method routines allow you to interact with the objects inside the DLL.

Oh gosh no, haha.

It's for that experimental object pascal compiler.

• All the standard editing features

• Sync edit

• Code snippets

• Char chart (access chars such as trademark, copyright, etc.)

• Code completion

• Parm hints

• Context help (completion, hints and this all powered by the compiler, so it knows the difference between TClass1.Test vs. derived TClass2.Test for example and will take you to the correct place in the help file)

• Macro recording/playback

• Project templates (put in the template folder, add entry and instantly accessible)

• Save/Load workspaces

• Can send anonymous feedback inside IDE

• Display latest RSS feeds from the homepage

• Code folding (with user-defined {$REGION}{$ENDREGION} markers

• Dbl click on error line takes you to the location in the source

• Navigate code in code structure view

• Navigate and pick files in the file explorer view

• Lots more and to come (hopefully)

The compiler is exposed as a service (CaaS) so I can access all features of it from a simple API:

Call Compiler_CodeCompletion with the code you're currently editing, and it will do a partial compile and return data that you can use for code completion/param hints. Pass the word the cursor is under to Compiler_FindDeclaration, and you can use this info to lookup an entry in the help file for context help. Compiler_GetErrorMessage return info that allows you to navigate to the source file location of error. At the moment, the compiler can produce standard win32 EXEs/DLLs. The game library uses Allegro5.

• Code is easier to read and understand, as it is more verbose and there are less "symbols" and more "words". Sometimes is like write pseudocode. Note that this doesn't mean it's slower to write because Delphi, Lazarus, FP IDE and others (such as Vim) include autocompletion features to write code quite fast (for example, you enter "BEGIN" and IDE adds "END;" automatically, or enter "TRY" and it will add "FINALLY/END;", etc.

• Better object model (IMO ): all objects are referenced, no "automatic" ones. That was borrowed by Java, Go and others.

• Faster compilation time.

• Executables aren't bigger than C/C++ ones, if so that's because you are not using the compiler correctly: by default, Pascal compilers adds extra code and information to the executable for safer execution and debugging. Unfortunately, some of that extra code makes some AV to detect false positives on some programs.

• About that extra code to build safer executables, this remembers me a bug on Allegro 4 that prevented to render a textured 3D polygon correctly in some cases, that was because it wrote outside the assigned memory, and was detected because the additional "extra code" added by the Pascal compiler detected it. Can't find the Allegro.cc thread where we discussed such bug.

• Better modularity: UNITs included encapsulation and name-space even in non-object oriented dialects since at least Turbo Pascal 1 (the very early '80s).

Can't remember more right now.