Support for set accessors?

[benhoefer]

Are there plans to support accessor assignment methods?  Right now if you create an accessor set function as below, it does not show the equal sign in Intellisense.

Code:

def data=(val)
  @data = val
end

If there are both a get/set accessor method, then Intellisense uses the first one that is defined.  I'm not sure if this is possible to support.  Normally this is just a nice to have, however, if the set method is first then intellisense does not understand that something is returned.  For example, if I have the following methods defined in this order.

Code:

# Set accessor
#:arg: x => String
def data=(val) @data = val; end

# Get accessor
#:return: => String
def data() @data; end

Then if I type the following:

Code:

one = Foo.new()
one.

--> At this point it does not give me the intellisense data for the String class because it is refering to the set accessor which does not return anything.

[Huw Collingbourne]

Let me be sure I understand this. Are you saying that, given this...

Code:

class Foo
def data=(val)
  @data = val
end

# Set accessor
#:arg: x => String
def data=(val)
  @data = val
end

# Get accessor
#:return: => String
def data()
  @data
end

end

...if you enter...

Code:

one = Foo.new
one.

...then the IntelliSense after one. should show string methods? That wouldn't be correct, however. When I try this, one. gives the data method on Foo which is correct. If I now write this...

Code:

one.data.

...I get string methods (due to the type assertion over the data method) which is also correct. Have I misunderstood this? If so, please post a clarification and I'll take another look.

best wishes

Huw

[benhoefer]

Oops, I'm sorry for the type, I did mean the following.

Code:

one.data.

I notice now that it does actually come up about 60-70% of the time.  It is acting very strange for me.  With the first level at just "one." everything comes up 100% of the time.  However, when I use an accessor as above in the code block sometimes the new list doesn't come up for the returned object.  I've been trying to find out why but it seems completely random and does different things.

- Sometimes it brings up the list correctly
- If I type in the entire "one.data." without hitting tab to automatically fill in the "data" method, then sometimes it keeps the method list for the Foo class... but then sometimes it switches to the String class.
- Even when I hit tab to fill in the "data" method it is hit or miss.  I've tried doing it really fast, or pausing a second or so before hitting the period.

It is just really strange.  For some reason it is just missing it randomly.  I've probably typed that line 300 times now. 

[benhoefer]

Another note is that i have the "Display object methods" turned off for intellisense.  When I turn this back on the list comes up 100% of the time.  But 60% of the time it does not have the string methods included.  So it seems that it is not an issue with Intellisense popping up, but that it isn't complete for some reason.

[Huw Collingbourne]

Hi Ben

There are two things to bear in mind about IntelliSense.
1) When code is not valid (that is, if it can't be run by Ruby) the IntelliSense system cannot analyze it. So if, for example, there is a syntax error (even a trailing dot that's been left lying around after an object name) you will need to fix that for the IntelliSense analyzer to do its job.
2) Due to the dynamic nature of Ruby, we have to analyze an awful lot of code for every single editing change. This is because even something as simple as the addition of a 'free-standing' method gets bound into the base Object in Ruby and, if it's public, this needs to percolate through to all other classes. To see what I mean, try this (make sure Object methods are displayed - Tools, Options, Text Editor, Ruby, IntelliSense, Display Object methods):

Code:

def aaa
end
public :aaa

a = Array.new
a.

After a. you should see the aaa method in the completion list (this is correct in Ruby). To analyze changes correctly, then, the IntelliSense system frequently has to reanalyze the entire class library. This is not, therefore, as fast as with a statically typed language such as C# in which the IntelliSense system never has to worry about complicated 'side effects' of this sort. We've made it reasonably fast, I think, and we are working on ways to make it even faster. But there may, even so, be times when the IntelliSense database is not fully up to date - especially if you are a fast typer or have a slow PC. If you suspect that the IntelliSense is not up to date you can force a reparse of the IntelliSense database by selecting Compile (press Ctrl+F7).

If, on the other hand, you find that this is a repeatable problem which may be due to some other factor, please send us a complete working example of the code and we'll take a closer look at it.

best wishes
Huw

[benhoefer]

Okay, after some more trials I am able to reproduce something.  It is not exactly the same but it illustrates it. Here's the code:

Code:

class Foo
 
# Set accessor
#:arg: val => String
def data=(val)
  @data = val
end

# Get accessor
#:return: => String
def data()
  @data
end

end

a = Foo.new()

Here is what I am doing.  I place the cursor at the end of the last line and press Ctrl-F7 to compile.  Then I hit enter, and type "a.da<tab>" and now I have "a.data" on the line.  Now if you press period right away you do get the correct list.  If you wait about 2-3 seconds and then press period, it does not have the correct list.

This really isn't a big deal, as I said before, it is just strange.  I do understand the challenges of intellisense with Ruby so it may just be a matter of hitting the period at a "bad time" with what Steel is doing in the background... who knows.  Also, maybe if you are using the dev version it is faster and already has some improvements.

[Huw Collingbourne]

Thanks for the example. I can reproduce that. We'll take a look at it and see if we can figure this one out... 

all the best

Huw

[Dermot]

One of the really wierd things about Ruby is that a dot doesn't terminate a line. So you can have something like:

x.
y

and Ruby will treat it as x.y so it's syntactically correct

I'm not saying this is happening here, but's it's something to look out for.

Dermot

[Dermot]

OK - fixed.