[Mono-osx] Delphi Prism and all those Cocoa bridges

[Matt Emson]

Andrew Brehm wrote:

I was off the radar yesterday, so apologies for tardy reply:

>
> The only downside is that using that method I won't have a single EXE with
> no DLL requirement that will run on both platforms (and look terrible on the
> Mac).
>   
This is a DOS mentality, unfortunately. Long gone are the days of 
2single exe". Even with Win32 pure development, the programmer relied on 
underlying DLL's existing. This should never be an issue, but often was. 
Windows didn't really address this issue properly - it made it easy to 
continue with the practice of "hope the user installed the right version 
of DLL X". From Win 2000 onwards, we've been pushed towards using 
installers. Installers should create a subdirectory containing support 
files that is completely opaque to the user of the system. Indeed in XP 
onwards, users are discouraged from looking in the Program Files 
directory by default (all users, even Administrator.) The contents of 
that directory can contain whatever the developer wants - there's no set 
rules. Indeed, iTunes, for example, contains a structure not unlike an 
App Bundle to varying degrees (there was a version around 6 that was 
almost identical, but the directory contents varies between major 
revisions.) Visual Studio 2005 has a mess of folders, Delphi 5.0 used to 
have a structure that split files between folders like {$InstallDir}\bin 
and {$InstallDir}\lib. Putting the App bundle in to a directory and 
creating a shortcut to the executable is not a crime. I don't see this 
as an issue at all.


> But I can add a fourth project if I want to support Linux and Gtk#.
>   

I have an app I work on at work. Parts are legacy VB, parts are C#. I 
have over 30 projects for various chunks of business logic and support 
functionality. If using Visual Studio, embrace the project concept. It 
really works well. One solution, many projects makes for a happy camper. 
The fact you can then add project references - genius! Debugging is then 
seamless between languages and projects.

> Cocoa lacks the regular expressions and portability but has the best
> right-to-left script support. (But it wants me to understand memory
> management, which is always a bad move for a programming language.)
>   
Objective-C 2.0 has garbage collection properly integrated, so that is 
not entirely true. Having used the Compact Framework version of .Net on 
memory constricted devices (Pocket PC) you do begin to hit a memory wall 
after a while. There's a big trade-off to throwing away the explicit 
memory management in a low memory situation. The programmer still has to 
know how to force garbage collection to happen to free up memory, but 
then has to rely on the Garbage collection to actually work properly and 
quickly enough to not hang the system due to low memory.. It only takes 
a bit of badly written/memory leaking code (*cough* Mobile SQL Server 
*cough*) to throw the "cat amongst the pidgins" and cause radical and 
sometimes overly elaborate memory clearing scheme to be necessary. It 
sometimes makes you wonder if Garbage collection is all it is cracked up 
to be. Indeed, even though I just mentioned Objective-C 2.0 allows auto 
deletion in a much more effective way (proper Garbage collection), the 
iPhone SDK does not seem to allow auto deletion to be used, which makes 
a lot of sense and corresponds to what I've just said.

M