FEATURE REQUESTS

[duckinator]

All feature requests go here.

Since <=1.0 is effectively in a feature freeze, we want to avoid spamming the issue tracker with new feature requests until it's out the door. At the same time, we don't want to lose all of these ideas, so if you have a new feature request, please leave a detailed explanation in a single comment, and defer further discussion until after 1.0 is out and working nicely.

If you don't want to get an email every time, you can mute this issue entirely. Yes, that option does exist, ndd.

[duckinator]

Static if. Like if, but at compile-time.

static if(unix || apple) {
    // ohai, I'm on a UNIX or Apple system!
} else if (windows) {
    // ohai, I'm on a Windows system!
} else {
    // ohai, I'm on...something else!
}

I believe clay has something along these lines, but don't hold me to that.

[alexnask]

Feature request number 1
Add an "?=" operator or something similar. Here is an example to demonstrate its usage

a: String
b := getSomeString()

a ?= b
// Equivalent to
a = b ? b : a

Feature request number 2

Add a "version" preprocessor, refer to #404

That's all :)

[alexnask]

Feature request number 3

Add an "Http" module to the sdk under the net directory containing simple HttpRequest and HttpResponse classes.

[alexnask]

Feature request number 4

Use interfaces in the new sdk. For example, a "Readable" or "Comparable" interfaces would be nice

Readable: interface {
    toString: func -> String
}

Comparable: interface {
    gt?: func(This) -> Bool
    lt?: func(This) -> Bool
    eq?: func(This) -> Bool
}

// ... 
LLong: cover from signed long long implements Readable, Comparable {
    // ...
    toString: func -> String { /* ... */ }
    gt?: func(other: This) -> Bool { this > other }
    lt?: func(other: This) -> Bool { this < other }
    eq?: func(other: This) -> Bool { this == other }
}

Why? Because generics, that's why!

[duckinator]

I don't understand interfaces in their entirety, but overall using them sounds like a good idea -- why not use all the features we can, if they simplify things?

However, a couple things specific to your examples:

1. I'm unsure what the purpose of gt? lt? and eq? are, if they're defined by the symbols.
2. I think you goofed with LLong lt?(): { this Bool { this == other }

[alexnask]

@duckinator Formatting issues ;)
Well, for LLong's eq?, gt? and lt? are defined by their operators because they are translated down to C, however you could implement the Comparable interface for other classes where it would be more useful. Also, you could then implement the < operator like:

operator < (left, right: Comparable) -> Bool { left lt?(right) } // etc.

Note that with the above implementation of Llong this would result in an infinite loop however I see no other way of doing this without being able to define extern operators (explicitely tell rock what operators will be translated directly to C)

[alexnask]

Here are a couple of additional feature @nddrylliog mentioned should be implemented for rock-1.0

Number one: Parenthesis-free if, else if, while (, for?) statements

if true {
    "Is always executed" println()
}

while x > 0 { /* ... */ }

Number two: String interpolation using #{}, a la Ruby

foo : String = getSomeValue(String)
"OHAI THERE #{ foo }" println()

id : String = getSomeValue(Int)
"You are suspect number #{ id }!" println()

Baz: interface { toString: func -> String }
baz : Baz = getSomeValue(Baz)
"Your baz is #{ baz }" println()

Should get translated to:

foo : String = getSomeValue(String)
"OHAI THERE %s" format(foo) println()

id : String = getSomeValue(Int)
"You are suspect number %d!" format(id) println()

Baz: interface { toString: func -> String }
baz : Baz = getSomeValue(Baz)
"Your baz is %s" format(baz toString()) println()

While the following code should fail:

obj : Object = getSomeObject()
"Here is your object, man: #{ obj }" println() // Error: Object 'obj' of type 'Object' does not have a toString method.

[alexnask]

Also, a thought I've had for a while:
Explicitelly declaring extern operators, as in operators that get translated to themselves in C.
Right now, any cover from a C type can be added, multiplied, substracted etc. leading to possible errors during C compilation.
Extern operators would fix that bug and also some issues the ooc type system currently has.
One of these problems is the fact that numerical operations between an integer and a floating point is always of the type of the left number. For example, 1/1.0 is of type SSizeT :-/
This would be fixed with the following operator overload:

extern operator / (LLong, Double) -> Double

[duckinator]

With regards to string interpolation:

If every object has the appropriate toString() function, such as the following:

1    toString()  // == "%d" format(1)
"hi" toString()  // == "%s" format("hi") or `this`
1.0  toString()  // == "%f" format(1.0)
// ...

We could have Object toString() have a default. I'm not sure if this would be the best format to use for it, but it could be similar to ruby's:

>> class Foo; end
=> nil
>> Foo.new.to_s
=> "#<Foo:0x00000002954c30>"
>> Foo.new.to_s
=> "#<Foo:0x00000002954690>"
>> Foo.new.to_s
=> "#<Foo:0x00000002953fb0>"

With ruby, I'm not sure what the number is. If ooc uses something similar, perhaps that could be the memory address? It just needs to be unique.

[nddrylliog]

I've actually tried the 'toString in Object' thing before, but it failed - at least, you sure as hell can't get away with it for covers (ie. expect virtual function calls to work on class-less stuff).

It could be tried again though.

[nddrylliog]

(And I'm pretty sure it's the memory address in Ruby too — or at least the equivalent in the Ruby VM)

[duckinator]

http://ruby-doc.org/core-1.9.3/Object.html#method-i-to_s says:

---

to_s → string

Returns a string representing obj. The default to_s prints the object’s class and an encoding of the object id. As a special case, the top-level object that is the initial execution context of Ruby programs returns “main.”

---

So yea, I think it's the Ruby VM's equivalent of the memory address. I believe in one of the "alternative" implementations -- possibly rubinius? -- it actually is the memory address.

Either way, since ooc (as far as I know) doesn't have a concept of an "object id," the location in memory would probably suffice.

This might do the trick:

Object: class {
    toString: func -> String {
        "#<%s:0x%o>" format(this class name, this&)
    }
}

But I can't get rock/master to compile(?!?!?) so I can't test that code.

[nddrylliog]

@duckinator I had the exact same reasoning a year or so ago, and implemented the exact same toString method on object, but I remember running into problems.

[duckinator]

Well as soon as I beat rock into behaving, I'll try it out. Maybe it was a bug that's been fixed or something.