What Can Xojo Learn From Swift?

Off-Topic
1

Swift is grabbing a lot of attention and has some interesting features.

Are there features and ideas that can be easily (or not so easily) applied to a future Xojo version?

This is not a thread to discuss Xojo vs Swift. Just to see if we can make Xojo even better.

2

At first, it could be helpful, if we have an interface to the Swift functions, so that we can use the new features to extend Xojo.

3

I don’t know how interesting that would be. We need to make sure that all functionality in Xojo can also work on Windows, Linux…
Since Swift is Mac only, I think the importance is limited to mac only shops (unless you like releasing software that has different functionality on different platforms, which I don’t)

4

Swift is just a programming language, not a framework, so there is no change for us, since we already can work with Cocoa, the Objective C Runtime, etc through declares. Swift does the same thing as Objective C, just with a cleaner syntax.

5

Thats correct,

but I really hate objectiveC and I believe the future for Apple itself is Swift. The other point is, that more of us Xojo developers are beeing able to write plugins, especially those for Mac and iOs. When Xojo for iOS will come out I expect it to be very good but limited. With an interface to Swift, more of us are able to found own solutions in handling not supported tasks.

6

Swift could be a swift death for Xojo !

7

I’ve looked at it. It isn’t.

8

Two features I would want Xojo to adopt, or at least look into:

  • Implicit typecasting, so I could write dim x = 1 // Integer, dim y = 1.0 // Double, or dim z = s // String, because s is a string.
  • The Playground feature. Utter coolness.
9

Xojo Pairs needs deprecation in favor of Tuples (http://msdn.microsoft.com/en-us/library/dd233200.aspx). About the rest I believe I saw Joe saying something like “I know, maybe someday in the future” for things like Clojures, Lambdas, Generics, the current inline if(,), shorter optimized syntax (a+=1), etc, etc. Xojo needs another reboot, rather soon, maybe a redesign to bring it closer to the state of the art after the iOS compiler release.

10

[quote=94899:@Kem Tekinay]Two features I would want Xojo to adopt, or at least look into:

  • Implicit typecasting, so I could write dim x = 1 // Integer, dim y = 1.0 // Double, or dim z = s // String, because s is a string.
  • The Playground feature. Utter coolness.[/quote]
    You confused me by calling it implicit typecasting because the book refers to this as type inference. Xojo has this for constants already. Implicit typecasting sounds like a terrible thing, such as [code]Dim WorldNumber As Integer = 1
    Dim S As String = “Hello " + WorldNumber + " World”

I would like the string substitution though. I think their syntax is awkward “Hello \(WorldNumber) World” but it would make building dynamic strings much nicer.

Rick already brought up Tuples. While not new to Swift by any means, they too would be handy.

11

Type inference is what I meant.

12

I’d really like type inference. I’m currently doing some Go programming (love, love, LOVE Go) and in Go you don’t have to declare the type of a variable if the compiler can easily figure it out. You can just type

age := 23 name := "Mr. Wonderful"
and Go figures out that age is obviously an int and name is obviously a string.

The magic is in the := instead of a plain = or ==.

It doesn’t just work with primitives, it works with any kind of type, e.g., in Xojo you could type

f := New FolderItem

or

f := GetOpenFolderItem(foo)

without having to first dim f as folderitem.

The language is still strongly typed, but type inference makes it feel more like a scripting language, and it’s surprising how such a little thing makes coding flow better.

13

Until Swift is an entire multiplatform RAD, this is just a play on word :wink:

Just tried it. I would be cool for variables indeed.

14

The way I read the manual "Hello " + WorldNumber + " World" would be valid. I’m hoping it is, I think that’s more readable. I don’t have means of testing since I wasn’t going to become part of the mac program until my app was ready to release.

15

It may be, I don’t recall. Frankly, I hope that + is not used as both an addition and concatenation operator. But as long as there is no implicit typecasting, it can work out.

What I mean is in a language where implicit typecasting exists, String + Integer is ambiguous. Should String be converted to an nnteger and add the two, or should Integer be converted to a string and appended to String? With implicit typecasting, two operators are pretty much required, so String + Integer means addition whereas String . Integer means concatenation.

In languages with no (or little) implicit typecasting, the problem goes away because the developer must inform the compiler what action should be taken. In Xojo, this would be either Val(String) + Integer or String + Str(Integer). I’m more partial to no implicit typecasting, which I believe Swift is very strict about. It won’t even convert a UInt8 into a UInt16 without explicit typecasting.

16

This snippet is what got me thinking it was okay.

17

That is okay, because you are concatenating two strings. Those are all String + String operations, no ambiguity there.

18

I like having to use Dim. I can control the scope of variables, and there is no chance that I was use a variable before intended.

However, I would like to do:

dim f1 = new FolderItem
dim f2 = f1

I can understand an argument that the latter isn’t particularly clear, but it is more flexible. For example:

dim a as Integer = 1
dim b = a
dim c = a
dim d = a

Later on, if I decide I need doubles instead of Integer, I have to change just one line. Or perhaps something like this:

dim a = 1
dim b, c, d SameAs a

Just dreaming…

19

Personally I loathe compressed declarations like

dim a , b, c as integer, d as double, e as folderitem

and even
dim a , b, c as integer
dim d as double
dim e as folderitem

I try to

  1. never declare a variable far away from where its to be used.
  2. never declare more than one variable on one line (far to easy to overlook or get a declaration messed up if you have to change the type)
  3. never declare a variable more globally than necessary
  4. always be explicit even when type inference is available. I like to be explicit so I don’t have to go read the code just to figure out that “a is an integer” in a method that has maybe 100 lines (and maybe I interpret the typing differently than the compiler - which can happen and I’m wrong)
20

[quote=94912:@Thom McGrath]Implicit typecasting sounds like a terrible thing, such as [code]Dim WorldNumber As Integer = 1
Dim S As String = “Hello " + WorldNumber + " World”[/quote]

That would be a wonderful thing, not a terrible thing. Overall I like Xojo better then VB.NET, but one of the things I appreciate about VB.NET is that it will make obvious typecasts for you. (Though with strings you need to use & for concatenation. If you use + sometimes the compiler will try to cast the wrong way.)

Note: I posted this and then saw your later message clarifying your problem with implicit typecasting. You’re right, the + symbol is ambiguous. But rather then lean towards no implicit typecasting at all, I wish we had a concatenation symbol that would trigger implicit typecasting.