Recently, I've started seeing some odd comparisons against Delphi that I had never really thought about before (or heard of), in places like the NUG or the forums. So when I noticed someone suggesting Delphi as an alternative to REALbasic because it built single file executables, I decided it was time to do some research and see what's up. It turns out that Delphi builds single file executables in exactly the same manner that REALbasic does (as well as numerous other languages, like C and C++). What Delphi does *not* do is the same as what REALbasic does not do:
August 2008 Archives
What the heck, why not stretch this topic out even more, right? ;-) One topic that's near and dear to my heart are compiler bugs. It's near because I'm the one who sees and fixes all of them, and it's dear because the compiler needs to be one of the most rock-solid, stable, reliable components to all of REALbasic. If you can't trust the compiler, then there's not much else you can trust! This is even more important since 2005, when we started using REALbasic to build the IDE. This post is going to talk about how compiler bugs are
In keeping with the bug reporting theme, reader Bob was wondering what sort of life cycle a bug report goes through at REAL. Since I'm not part of the testing staff, my answer might be slightly different from what someone like Kyle would say. Also, since I'm a programmer, I figured I'd give a tongue-in-cheek example program (note: it's not a very OOP example!). It's a life cycle, which is just fancy "human talk" for "algorithm", right? ;-) Sub Main() while not OutOfMoney report = GetIncomingReport() select case report.Type case Report.kFeatureRequest ProcessFeatureRequest( report ) case Report.kBugReport ProcessBugReport( report ) else
Lover of both oatmeal and coffee, Philip asks via the Suggestion Box for "Examples of bug reports spanning the spectrum of the best case to worse case, so that we have an idea of what you're looking for versus what users think you need." Ooh, this could be a touchy subject... I don't like calling people out on bug reports because I appreciate that it takes effort to file them in the first place. So I don't want to be mean and mock people's good intentions. Instead, I'm going to try to point out good feedback report examples, and then
This caused me a bit of confusion, and so I am hoping to prevent the same from happening to you. It has to do with Unicode code points, and how they relate back to interesting things like bits in memory. Code points are arbitrary numbers that represent unicode data. You see them expressed in the form U+XXXX, where X is a Hex digit. So, for instance, the letter A is represented by U+0041. These code points are just abstractions that allow us to assign a unique ID to something approaching a "letter" (the concept of letters and whatnot are just
In REALbasic, there are several ways to get data from one format into another format. But there are two main terms used to describe the process: type casting, and type converting. You're probably already used to implicit type conversion without ever even knowing it. This happens when you assign a value of one type to a variable of a different type. For instance: dim i as Integer = 3.2 This code implicitly converts from a Double to an Integer. In 2008r3, we added a new operator to the language called CType -- this is an explicit conversion operation. It behaves
Long-time reader Christian asked via the Suggestion Box for some examples of useful IDE scripting. Specifically, he was wondering how you'd automate a build, and perform a bit of file maintenance after the fact. Well, you're in luck, because I just so happen to have a bit of insights and useful tips on the topic! :-) To perform a build, you're going to want to use the BuildApp method, provided by the context object. This method takes an integer platform parameter, and it returns to you a string to the built application on disk, and it's duty is to synchronously
So now that REALbasic has the ability to declare types within classes, it makes sense to ponder the idea of allowing one of the more pervasive types to be declared within a class: another class. Let's take a simple example of what sort of problems this would solve. You have a project you're working on where you control a robotic arm via a serial communication link. Since you adhere to OOP as strictly as you can, you want everything to be as encapsulated and clean as possible. Part of the serial protocol is that you need to send a keep-alive
Philip asked via the Suggestion Box about what sort of coding standards and design philosophies do we use at REAL Software when working on REALbasic, so I figured I'd discuss that a little bit. We don't do anything too terribly radical, so much of this won't come as a surprise to you. We use two different languages to do our work: REALbasic is used when working on the IDE and parts of the framework, and C++ is used when working on the compiler and parts of the framework. So, without further ado, here's the coding standards we have (pulled straight
It's recently come up on the NUG that there is some confusion over division by zero, and what it should do. So I figured I'd take a stab at explaining the technical side of things. The problem is, what to do when the user writes code that divides by zero (whether by floating-point division, integer division or modulo operations). Let me start by describing what REALbasic already does. If you are dividing two values and expect to get a floating-point result, then the result is a sentinel value that represents positive or negative infinity, depending on whether an operand is
I touched on this briefly in a previous post about best practices in REALbasic, but I think the topic deserves its own post entirely. In REALbasic, constructors are initializer methods, not allocator methods. When you say "new SomeClass", the compiler allocates *all* of the space for SomeClass, and then calls the first constructor it finds in the class hierarchy like it would any other method. So constructors are slightly magical in that the compiler automatically calls a method when you use the "new" keyword. But they're not really that magical at all. They're basically just a regular virtual method like
When discussing language design, it helps for people to understand a few of the basic tenants I go by. At the very least, it will help you to frame discussions in a way that has more weight when it comes to pitching for something you're passionate about! ;-) REALbasic is its own language. It certainly borrows concepts from other languages, and sometimes syntax, etc. But REALbasic is not C++, nor is it Java, nor VB6, nor VB.NET, etc. But linguistically, REALbasic is unique and does its own thing for better or for worse. So saying "but C++ does it this
