[DUG] EMBARCADERO MY GRIPE

Wed Jul 29 08:13:18 NZST 2015

I guess for me, not ever seeing a role advertised that requires RemObjects
experience, I would be confined to tinkering with the free version of the
"Silver" tool.
And given its not main-stream, it would be hard to get it into our
development environment.
Thats not saying it itsnt a good tool, just the commercial reality.
However, like all of you, I am getting a little concerned about EMB.
direction. For me personally, having to re-install my controls every six
months or so is just not economic. Instead of releasing new versions ever 6
months or so, do one a year with six month updates that doesnt require me
to re-install all my controls.

Jeremy

On Wed, Jul 29, 2015 at 8:03 AM, Jolyon Smith <jsmith at deltics.co.nz> wrote:

> RemObjects # of users - sorry, I have no idea.
>
> Community support - there are two prongs to this...
>
> First, the RemObjects forums are quite active with contributions both from
> users and RemObjects staff thmselves.  To give an example of the type of
> support you get, on one occasion during my early days with the product I
> encountered a problem using a particular aspect of the Android SDK which
> was traced to an esoteric bug in the compiler.  This was identified in a
> few days and by the end of that week a build had been provided to me
> personally to test, before the fix was incorporated in a subsequent beta
> and later release build.
>
> As a subscriber you have access to the current and previous releases and
> betas and you also have a "private downloads" area where specific builds
> may be provided to you.  Betas are updated on a more or less monthly basis
> with full releases usually coming quarterly, along with regular updates on
> the development plans (a "roadmap" if you like" via the blog, as well as
> formal updates to those plans with each release (they tell you what the new
> release delivers and what they are working on next).
>
> http://blogs.remobjects.com/blogs/mh/2015/07/16/p7096
>
> I should add that I am enjopying only *BASIC* support.  Premium support
> is a cost-extra option, should you feel the need for it.
>
>
> Second, "Community Support" is also on offer from beyond the strictly
> delineated boundary of "RemObjects Users" itself. by virtue of the fact
> that you are developing directly against the platform SDK's.  I have
> learned all my Android and iOS development from the Java and Objective-C
> examples online and by perusing questions and answers on Stack Overflow
> couched in terms of those platform native languages and API's.  Applying
> that knowledge to RemObjects elements is a trivial exercise in syntax
> conversion.
>
>
> On the point of Java and "one language everywhere".... something to bear
> in mind here is that when you compile RemObjects Elements code - whether
> ObjectPascal (Oxygene), C# or Swift - for Android, what the compiler emits
> is Java byte-code.  It is indistinguishable from the output of a Java
> compiler!  The front end language syntax may be different, but the output
> is essentially Java.  This applies equally to consuming other Java code.
> Classes etc from Java are simply consumed directly in your code by adding
> the relevant JAR to your project references.
>
> So in a way, RemObjects Elements is an active participant in that "Java
> everywhere" phenomenon - when compiling for a Java platform.  In the
> Oxygene compiler they have cleaned up the syntax of some of the aspects of
> Java, whilst retaining this compatibility.  For example. Java has no formal
> specification for the concept of a "property".  But you can still declare
> properties in Oxygene for Java - the compiler emits corresponding getXXX
> and setXXX methods as you would expect (even if you have not explicitly
> declared these accessor methods).  Equally, if you consume a Java class
> (e.g. from the Android SDK) which implements get/set methods, then these
> can be accessed as if they were properties:
>
>    Java methods:    v = o.getName(); / o.setName(v);
>    Oxygene:            v := o.Name; / o.Name := v
>
> Similarly if provide your class implementing a read/write "Name" property
> to a Java developer (in a jar file) then they will see a class with getName
> and setName methods, just as they would normally expect.
>
> Equally when compiling for .net then Elements is an active participant in
> that ecosystem/platform.  And ditto w.r.t iOS / OS X when compiling for
> those platforms.
>
>
> As I think I said, impressive and innovative technology.  :)
>
>
>
>
>
> On 29 July 2015 at 00:25, John Bird <johnkbird at paradise.net.nz> wrote:
>
>>   I don’t know RemObjects C# or Oxygene.   I read the site and their
>> viewpoint on using native API’s is a worthwhile debate.    I would have
>> these queries:
>>
>> 1 – Where does it rate on the number of users?   Community support, code
>> snippets etc is as important as everything else.
>>
>> 2 – It is the opposite of “one language fits everywhere”   yet the
>> language currently scoring top on the Tiobe index of programming languages
>> does just that – Java.
>>
>> http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
>>
>>
>> I noticed Delphi is up another few places, to 13.   Pascal is rated
>> separately too at 20.
>>
>> On the comments about the IDE, at work have used D5 , D2007, XE2 XE5 XE7
>> XE8 and each version was a definite improvement.
>>
>>  *From:* Jolyon Smith <jsmith at deltics.co.nz>
>> *Sent:* Tuesday, July 28, 2015 5:03 PM
>> *To:* NZ Borland Developers Group - Delphi List
>> <delphi at listserver.123.net.nz>
>> *Subject:* Re: [DUG] EMBARCADERO MY GRIPE
>>
>>  I'll say it one more time... RemObjects manage to provide very good
>> support for good quality products with extensive, impressive and innovative
>> technology that does indeed "just work" (as in effortlessly, not "barely"
>> LOL) at a very reasonable price.  $49 Turbo Pascal it certainly isn't, but
>> lined up against the likes of Delphi and Xamarin and particularly after
>> adjusting for inflation (for comparison with the $49 TP) it isn't far off.
>>
>> Cheap(er) = lower quality is *not* a rule, and certainly not a Universal
>> Constant.
>>
>>
>>
>> _______________________________________________
>> NZ Borland Developers Group - Delphi mailing list
>> Post: delphi at listserver.123.net.nz
>> Admin: http://delphi.org.nz/mailman/listinfo/delphi
>> Unsubscribe: send an email to delphi-request at listserver.123.net.nz with
>> Subject: unsubscribe
>>
>
>
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post: delphi at listserver.123.net.nz
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-request at listserver.123.net.nz with
> Subject: unsubscribe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserver.123.net.nz/pipermail/delphi/attachments/20150729/79c841ee/attachment-0001.html 