Ist RemObjects die Zukunft von Delphi?

[sh17]

Bei .NET ist mir noch nicht ganz klar, worauf setzt man vernünftiger Weise? WPF (tot) WinRT (hmm) GTK# (+Linux), ...

[Furtbichler]

Zitat von sh17:

Bei .NET ist mir noch nicht ganz klar, worauf setzt man vernünftiger Weise? WPF (tot) WinRT (hmm) GTK# (+Linux), ...

WinForms fehlt in deiner Auflistung. Bloß weil WPF (und WinForms?) nicht weiterentwickelt wird, ist das doch nicht tot. Schau mal bei Microsoft nach, was die darüber schreiben. WinForms, WPF sind einfache Techniken, um Windows-Applikationen mit 'ner GUI zu schreiben. Wenn Du Metro Apps (meinst Du das mit WinRT) schreiben willst, bitte sehr.

Allerdings ist es schon so, das man für WPF etwas vom MVP/MVVM-Pattern verstehen muss, und für Metro/WinRT bestimmte Patterns und Techniken einsetzen muss. Wenn man den Sinn dahinter nicht versteht, dann bleibt man am Besten bei Delphi, Visual FoxPro und ähnlichen.

Ein guter Softwareentwickler macht sich ja mittlerweile doch unabhängig vom Frontend und schreibt seine Anwendungen so, das sie ohne großen Aufwand an andere GUI angepasst werden können. Insofern ist das doch ziemlich egal, was gerade in Mode ist.

[sh17]

MVP/MVVM-Pattern - vollkommen richtig - und WinRT-nein möchte ich eigentlich nicht nutzen.

Wenn ich nun schon versuche alle 3 "wichtigen" Plattformen nativ zu unterstützen, was ist der momentane (technische) optimale Weg?

Windows Linux MacOS
WPF GTK# Cocoa
WinForms WinForms Cocoa

[Lemmy]

Hi,

ich persönlich finde Oxygene bzw Hydrogene sehr interessant. Mit Prism/Oxygene bin ich aber nicht warm geworden - die Sprache gleicht zu sehr Delphi, das Backgroud ist aber ein komplett anderes. Der Umgang mit c# ist mir da wesentlich leichter gefallen, obwohl ich an c angelehnte Sprachen überhaupt nicht gerne mag.

Vor allem plattformübergreifend sehe ich RemObjects mit ihrem Toolset ganz klar vor Embarcadero. Leider habe ich aber Probleme damit meine Begeisterung (z.B. an Futures) an meine Kollegen weiter zu geben: die wollen nicht aus einer Nische in eine noch kleinere Nische wechseln

aber vielleicht kann ich die jetzt mit Hydrogene ködern - ist immerhin C#. Zwar deutlich erweitert, aber mir käme ein Framework sehr gelegen das die Hauptplattformen abdeckt - das wäre mit Oxygene/Hydrogene gegeben.

Zumindest für mein privates Zeugs werden Alternativen zu Dephi immer interessanter - so leid es mir auch um Delphi tut....

[Der schöne Günther]

Zitat von Lemmy:

[...] mit Hydrogene ködern - ist immerhin C#. Zwar deutlich erweitert,[...]

Ich dachte, genau anders herum?

[Lemmy]

Zitat von Der schöne Günther:

Zitat von Lemmy:

[...] mit Hydrogene ködern - ist immerhin C#. Zwar deutlich erweitert,[...]

Ich dachte, genau anders herum?

Wie meinen?

[Phoenix]

Zitat von Lemmy:

Zitat von Der schöne Günther:

Zitat von Lemmy:

[...] mit Hydrogene ködern - ist immerhin C#. Zwar deutlich erweitert,[...]

Ich dachte, genau anders herum?

Wie meinen?

Hydrogene ist C# (für .NET) bzw. ein Subset von C# für die Cocoa/Objective-C Runtime (z.B. gehen dort keine Generics, da das die Runtime nicht kann). Das was hier erweitert wurde ist z.B. der für Cocoa benötigte Support für Multipart-Method Names.

Ansonsten ist das "nur" ein Compiler mit 3 Backends (.NET, Java Bytecode, Obj-C) für die Sprache C# - da ist nichts "deutlich" erweitert, sondern nur minimal wo unbedingt nötig.

[Lemmy]

Zitat von Phoenix:

Ansonsten ist das "nur" ein Compiler mit 3 Backends (.NET, Java Bytecode, Obj-C) für die Sprache C# - da ist nichts "deutlich" erweitert, sondern nur minimal wo unbedingt nötig.

ähm.. Oxygene wird ja z.B. mit "Futures" beworben - ich bin davon ausgegangen dass solche Sprachfeatures auch in c#-Hydrogene dabei sind... auf das bezog sich das erweitert....

[jensw_2000]

Zitat von Phoenix:

Hydrogene ist C# (für .NET) bzw. ein Subset von C# für die Cocoa/Objective-C Runtime (z.B. gehen dort keine Generics, da das die Runtime nicht kann). Das was hier erweitert wurde ist z.B. der für Cocoa benötigte Support für Multipart-Method Names.

Ansonsten ist das "nur" ein Compiler mit 3 Backends (.NET, Java Bytecode, Obj-C) für die Sprache C# - da ist nichts "deutlich" erweitert, sondern nur minimal wo unbedingt nötig.

Hi,
das ist nicht ganz richtig. Ich habe gerade mein frisch installiertes RO C# gestartet und 2 Sachen probiert:

Delphi-Quellcode:

class RootViewController : UIViewController

{
private NSArray<String> MyStringarray = new NSArray<String>;  // Generics gehen unter iOS / Linq auch :o)
private Class1 MyPascalClass; // das ist der Hammer. Eine Oxygene (Pascal) Klasse im gleichen Projekt. Kompiliert und rennt :o))

 ...
}

Noch ein PS:
Man kann auch CS Dateien in Oxygene Projekte hängen und die Klassen normal benutzen. Gerade getestet mit einem DevExpress C# Template. 
Ich tauche dann mal für ein paar Tage unter. Muss jetzt unbedingt mal schnell alles umbauen ;)

PS:
und für Furtbichler, unserem Prediger für "sprechende Methodennamen und Parameter"

RO C# kann laut RemObjects 100% des MS C# zzgl. der Gimmicks die RO mit eingebaut hat.
Die Multipart Methodnames sind glaube ich genau das richtige für deinen Geschmack.

Code:

namespace ConsoleApplication1
{
   static class Program
   {
      public static Int32 Main(string[] args)
      {

                        LogAdditionResultOfInt(1) AndInt(2);
                        return 0;
      }

        private static void LogAdditionResultOfInt(int Summand1) AndInt(int Summand2)
        {
            Console.WriteLine("{0}+{1}={2}",Summand1,Summand2,Summand1+Summand2);
        }
        
    }
}

Ausgabe:
1+2=3
wäre zur Not auch im Kopf gegangen, aber die Multipartnames liebe ich seit iOS.

[stahli]

Ich bin noch an einem Projekt, bei dem ich weiter bei XE3 und VCL bleibe.

Etwas neues werde ich bei Emba nicht mehr kaufen.

RemObjects wirkt deutlich attraktiver und kompetenter.

Mir graut etwas vor einem Wechsel, insbesondere wegen meinem schlechten Englisch. Mit .NET wollte ich mich zwar ursprünglich nicht anfreunden, aber wenn es keine gute Alternative gäbe...!?

Vielleicht ist mittelfristig auch eine www.RO-Praxis.net denkbar. ?