Audio podCast

5 – Oxygene and .NET

Back in episode 2 Nick Hodges told us to learn the latest features of .NET since the future version of Delphi for .NET will have full support of all .NET features.  Instead of learning C# or VB.NET, we can use Oxygene by RemObjects.  In this episode we talk with marc hoffman of RemObjects about Oxygene – the surprisingly complete Object Pascal implementation for .NET.

Also a note about last week’s episode: In addition to all the great information on using generic collections, I also had asked our guest, Julian Bucknall, some questions about the implementation of the TDictionary class.  Julian did not write this class, nor did he heavely research the code.  He did  tell me how he understood it worked.  Well it turns out he a missunderstood some of the implementation details.  Barry Kelly, the author of that class added some comments on the show notes for that show.  Check those comments out for a correction on the implementation of the generic TDictionary in Delphi 2009.

5 replies on “5 – Oxygene and .NET”

Nice one.:-)

Want to extend a bit on the future stuff. I guess this is quite hard to communicate w/o video and source code.

There is the new kind of type “future X”, but 2 different runtime behaviors…

The first and most simple one is what I call “lazy loading”.
It means that the code will get executed, when you access the value for the first time:
var xyz : future Integer := SomeLengthyCall();

// some in-between code

// the call gets invoked here and the result stays cached in “xyz”
// we still have to wait the full time here
if xyz > 5 then

The other implementation is what I call “async futures”. This is the more exciting and useful way to use futures, IMO.
An async future will be executed immediatly, but in a different thread.

// type inferrence for async calls always results in a” future X”
var xyz := async SomeLengthyCall();

// some in-between code

// the call got invoked at declaration
// if it hasn’t returned yet, the first access to the value will block
// the thread until the call returned, further calls directly return the value
if xyz > 5 then

btw, when you have reference the System.Threading.dll from the ParallelFX, Oxygene will use PFX’ tasks rather than the .Net threadpool.
And this means that PFX will make sure that there are only a sensible count of active threads running at once.

Hope that helps a bit in understanding futures…


Why does RemObjects use ASP for their own website? Why not Oxygene? Any chance RemObjects will port MojoPortal, or any other CMS, to Oxygene? That would be a very useful sample that could ship with the product. I’m excited about the future of Oxygene, but unless there a few real world helper apps, I’m afraid adoption will be slow. Oxygene has a great feature set, I’m just waiting for some great examples.




the code and infrastructure driving our current website is older than Oxygene, in fact older than RemObjects itself – it’s based on stuff i implemented years before we started the company, it’s always been working great and frankly, there never was a reason to redo everything just for the sake of redoing it (also, redoing it would have meant redoing *everything*, as ASP and ASP.NET do not mix easily, as far as infrastructure such as session management, etc is concerned.

so not being done in Oxygene is not a function of it not being a great tool, but more of us having an already working solution, and not having the time to reinvent the wheel just for the fun of a rewrite.

we (mostly, i) are currently working on a brand new set of websites, to be launched soon, and those new websites (actually 2 web projects, that will serve four different sites) is being written using Oxygene and DA LINQ. since this was to be a completely new endeavor anyways, it made sense to pick a new set of tools, and Oxygene was the right one for the job, now.


Comments are closed.