xraid (sorry, I don’t know your real name) tried to clean up
examples/fields.duby by having the constructor assign a new ArrayList.
However the existing syntax was my attempt to do a type declaration +
assignment to null, which unfortunately no longer appears to work.
The problem is that since we don’t have a specific field declaration
syntax (Ruby doesn’t have one) we just declare fields to be whatever
type we first assign to them. That’s not ideal; it means @a =
ArrayList.new will be of type ArrayList rather than List or
Collection, and declaring the field requires something like I had in
fields.duby: @a = ArrayList (with no .new).
So perhaps we should discuss how field declaration should work. Unlike
Ruby, we need to have all fields declared at compile time, so we need
something.
Current:
class Foo
def initialize @a = ArrayList (the “a” field will be declared as type ArrayList
and assigned null)
The problem is that since we don’t have a specific field declaration
syntax (Ruby doesn’t have one) we just declare fields to be whatever
type we first assign to them. That’s not ideal; it means @a =
ArrayList.new will be of type ArrayList rather than List or
Collection, and declaring the field requires something like I had in
fields.duby: @a = ArrayList (with no .new).
Maybe this was meant for the duby list?
Either way I’ll pipe in.
Maybe a syntax like
def list(a:ArrayList.of(Hash.of(:int))
end
or something. well, that does look somewhat ugly, but hey
-rp
ArrayList @a is actually the faster to write (at least in my latin 1
keyboard)
@a:ArrayList requires me to press shift + . for producing a :, (I can’t
pinpoint it exactly but this makes my eyes hurt!) @a : ArrayList requires two extra spaces for the overall prettiness. @a = ArrayList same thing
Arraylist @a also has the advantage that we only have on way to write
it, and it is more familiar to Javists (sry about the name calling)
Taking this argument longer, what would be the effort to be able to
make it consistent with the type declaring on method parameters like
def method(ArrayList a)
…
end
Cheers,
Luis Landeiro R.
On 02/19/2010 05:56 PM, Charles Oliver N. wrote:
fields.duby: @a = ArrayList (with no .new).
and assigned null)
Oops, yes, this was supposed to go to the Duby list. I’ve copied it on
this reply. My original post and additional replies follows below.
Collection, and declaring the field requires something like I had in @a = ArrayList (the “a” field will be declared as type ArrayList
None of these are particularly hard to compile.
Charlie
On Tue, Feb 23, 2010 at 6:21 PM, Peter Sönnergren Lind [email protected]
wrote:
+1 for the icky Java style
ArrayList @a
It just makes my skin crawl for some reason, but it may be the clearest
option.
Because the others look like they might means something else in Ruby
@a=ArrayList
could mean assign value of constant ArrayList to @a @a:ArrayList
at least for local variables looks too similar to 1.9 hash syntax using
symbols as keys
Another option I used in my port of the Benchmarks Game’s binarytrees
algorithm is to just use casting syntax to cast a nil:
@a = ArrayList(nil)
Then we’re only leaning on normal Duby casting and type inference (via
assignment) rather than introducing a new declaration concept.
Arraylist @a also has the advantage that we only have on way to write
it, and it is more familiar to Javists (sry about the name calling)
Taking this argument longer, what would be the effort to be able to
make it consistent with the type declaring on method parameters like
def method(ArrayList a)
…
end
Well, if we wanted Java syntax, we could provide a Duby frontend that
just uses Groovy’s parser+AST
Because Duby is of Ruby heritage, I’d like to try to keep the syntaxes
feeling as “Ruby” as possible, but I’m open to all suggestions
(including the not-so-crazy idea of multiple syntax frontends that
feed the middle tiers of the Duby compiler chain).
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.