I am new to Ruby, and I am currently working with an API which is unfamiliar to me. In order to use code completion, which helps me learn, I installed RadRails in Eclipse. However, I am having trouble with Content Assist: specifically, the Content Assist does not reveal the methods for objects in the API.
For example, one of my objects, ins, represents a loaded XBRL instance document. If I run ins.methods, the list contains all of the methods I want, including those in the API (such as functions that allow me to access items in the instance):
...
item
item_all
item_all_groupby_vocab
item_all_map
item_by_vocab
item_ctx_filter
...
etc.
However, if I just type ins. with Content Assist enabled, it only shows options like:
dclone
gem
gem_original_require
JSON
Pathname(path)
...
etc.
which appear to be system options. As a result, the Content Assist exposes exactly zero of the methods I actually want to use. If I know the methods ahead of time and start typing them, I can get Content Assist to give them to me, eventually, by pressing Ctrl+Space. However, that requires me to know what I want ahead of time; since I am using this to explore the API, that doesn't work for me.
Does anyone know how to get RadRails/Eclipse to show me the correct methods?
Regards,
Matt
This is a general problem inherent to dynamic languages and IDEs/editors. The IDE has to guess at the type of the variable that the code assist is being invoked upon, and from that generate the list of applicable methods.
IRB has type information at runtime, so it knows what methods apply. The IDE is trying to guess the type by analyzing your code statically (not running it).
Having said that, the IDE should often be able to guess correctly. Providing the larger context of the snippet of code that this is being invoked on would be helpful to look into whether or not we could provide helpful content assist on this object. You may want to file a ticket with the version number, and the sample code here: http://aptana.com/r/apbugs
Related
I am trying to see if there is a way to get the contents of a datagridview that is inside a top level window using Windows API's. I am using Visual Basic for this, but could also use C.
I doubt you could use the WinAPI to drill into a .NET app's DGV to get any meaningful information. But you might be able to using Reflection which enables you to obtain information about assemblies and the types defined within them, such as classes, interfaces, and value types. The ops are contained in the System.Reflection namespace.
Its fairly slow, so it is often a last resort, and the methods and such are pretty dense (convoluted) because you are getting at the information the 'long way around' by examining the Types and then asking the type for information.
This project shows how to access information in a different executing assembly. Given enough time and work and study, it should give you an idea how to do what you are asking.
I am learning Ruby and I'm having a major conceptual problem concerning typing. Allow me to detail why I don't understand with paradigm.
Say I am method chaining for concise code as you do in Ruby. I have to precisely know what the return type of each method call in the chain, otherwise I can't know what methods are available on the next link. Do I have to check the method documentation every time?? I'm running into this constantly running tutorial exercises. It seems I'm stuck with a process of reference, infer, run, fail, fix, repeat to get code running rather then knowing precisely what I'm working with during coding. This flies in the face of Ruby's promise of intuitiveness.
Say I am using a third party library, once again I need to know what types are allow to pass on the parameters otherwise I get a failure. I can look at the code but there may or may not be any comments or declaration of what type the method is expecting. I understand you code based on methods are available on an object, not the type. But then I have to be sure whatever I pass as a parameter has all the methods the library is expect, so I still have to do type checking. Do I have to hope and pray everything is documented properly on an interface so I know if I'm expected to give a string, a hash, a class, etc.
If I look at the source of a method I can get a list of methods being called and infer the type expected, but I have to perform analysis.
Ruby and duck typing: design by contract impossible?
The discussions in the preceding stackoverflow question don't really answer anything other than "there are processes you have to follow" and those processes don't seem to be standard, everyone has a different opinion on what process to follow, and the language has zero enforcement. Method Validation? Test-Driven Design? Documented API? Strict Method Naming Conventions? What's the standard and who dictates it? What do I follow? Would these guidelines solve this concern https://stackoverflow.com/questions/616037/ruby-coding-style-guidelines? Is there editors that help?
Conceptually I don't get the advantage either. You need to know what methods are needed for any method called, so regardless you are typing when you code anything. You just aren't informing the language or anyone else explicitly, unless you decide to document it. Then you are stuck doing all type checking at runtime instead of during coding. I've done PHP and Python programming and I don't understand it there either.
What am I missing or not understanding? Please help me understand this paradigm.
This is not a Ruby specific problem, it's the same for all dynamically typed languages.
Usually there are no guidelines for how to document this either (and most of the time not really possible). See for instance map in the ruby documentation
map { |item| block } → new_ary
map → Enumerator
What is item, block and new_ary here and how are they related? There's no way to tell unless you know the implementation or can infer it from the name of the function somehow. Specifying the type is also hard since new_ary depends on what block returns, which in turn depends on the type of item, which could be different for each element in the Array.
A lot of times you also stumble across documentation that says that an argument is of type Object, Which again tells you nothing since everything is an Object.
OCaml has a solution for this, it supports structural typing so a function that needs an object with a property foo that's a String will be inferred to be { foo : String } instead of a concrete type. But OCaml is still statically typed.
Worth noting is that this can be a problem in statically typed lanugages too. Scala has very generic methods on collections which leads to type signatures like ++[B >: A, That](that: GenTraversableOnce[B])(implicit bf: CanBuildFrom[Array[T], B, That]): That for appending two collections.
So most of the time, you will just have to learn this by heart in dynamically typed languages, and perhaps help improve the documentation of libraries you are using.
And this is why I prefer static typing ;)
Edit One thing that might make sense is to do what Scala also does. It doesn't actually show you that type signature for ++ by default, instead it shows ++[B](that: GenTraversableOnce[B]): Array[B] which is not as generic, but probably covers most of the use cases. So for Ruby's map it could have a monomorphic type signature like Array<a> -> (a -> b) -> Array<b>. It's only correct for the cases where the list only contains values of one type and the block only returns elements of one other type, but it's much easier to understand and gives a good overview of what the function does.
Yes, you seem to misunderstand the concept. It's not a replacement for static type checking. It's just different. For example, if you convert objects to json (for rendering them to client), you don't care about actual type of the object, as long as it has #to_json method. In Java, you'd have to create IJsonable interface. In ruby no overhead is needed.
As for knowing what to pass where and what returns what: memorize this or consult docs each time. We all do that.
Just another day, I've seen rails programmer with 6+ years of experience complain on twitter that he can't memorize order of parameters to alias_method: does new name go first or last?
This flies in the face of Ruby's promise of intuitiveness.
Not really. Maybe it's just badly written library. In core ruby everything is quite intuitive, I dare say.
Statically typed languages with their powerful IDEs have a small advantage here, because they can show you documentation right here, very quickly. This is still accessing documentation, though. Only quicker.
Consider that the design choices of strongly typed languages (C++,Java,C#,et al) enforce strict declarations of type passed to methods, and type returned by methods. This is because these languages were designed to validate that arguments are correct (and since these languages are compiled, this work can be done at compile time). But some questions can only be answered at run time, and C++ for example has the RTTI (Run Time Type Interpreter) to examine and enforce type guarantees. But as the developer, you are guided by syntax, semantics and the compiler to produce code that follows these type constraints.
Ruby gives you flexibility to take dynamic argument types, and return dynamic types. This freedom enables you to write more generic code (read Stepanov on the STL and generic programming), and gives you a rich set of introspection methods (is_a?, instance_of?, respond_to?, kind_of?, is_array?, et al) which you can use dynamically. Ruby enables you to write generic methods, but you can also explicity enforce design by contract, and process failure of contract by means chosen.
Yes, you will need to use care when chaining methods together, but learning Ruby is not just a few new keywords. Ruby supports multiple paradigms; you can write procedural, object oriend, generic, and functional programs. The cycle you are in right now will improve quickly as you learn about Ruby.
Perhaps your concern stems from a bias towards strongly typed languages (C++, Java, C#, et al). Duck typing is a different approach. You think differently. Duck typing means that if an object looks like a , behaves like a , then it is a . Everything (almost) is an Object in Ruby, so everything is polymorphic.
Consider templates (C++ has them, C# has them, Java is getting them, C has macros). You build an algorithm, and then have the compiler generate instances for your chosen types. You aren't doing design by contract with generics, but when you recognize their power, you write less code, and produce more.
Some of your other concerns,
third party libraries (gems) are not as hard to use as you fear
Documented API? See Rdoc and http://www.ruby-doc.org/
Rdoc documentation is (usually) provided for libraries
coding guidelines - look at the source for a couple of simple gems for starters
naming conventions - snake case and camel case are both popular
Suggestion - approach an online tutorial with an open mind, do the tutorial (http://rubymonk.com/learning/books/ is good), and you will have more focused questions.
I want to store brief snippets of code in the database (following a standard signature) and "inject" them at runtime. One way would be using eval(my_code). Is there some way to debug the injected code using breakpoints, etc? (I'm using Rubymine)
I'm aware I can just log to console, etc, but I'd prefer IDE-style debugging if possible.
Hm. Let's analyze your question. Firstly, it does not seem to have anything to do with databases: You simply store a code block in the source form somewhere. It can be a file, or a database. Secondly, you don't want IDE-style "debugging", but TDD-style. (But don't concentrate on that question now.)
What you need, is assertions about your code. That is, you need to describe what output should your code produce given some input examples. And then, you need to run that code and see whether its function matches the expectations. Furthermore, if you are not sure about the source of your snippets, run them in a sandbox (with $SAFE = 4). If your code fails the expectations, raise nice errors (TypeError, or even better, your custom made exception), and then you can eg. rescue those exceptions and eg. use some default code snippets...
... but maybe I'm not actually answering the same question that you are asking. If that's the case, then let me share one link to this sourcify gem, which let's you know the source, so that you can insert a breakpoint by saying eg. require 'rdebug' in the middle of code, or can even convert code to sexps. That's all I know.
I'm looking into writing an addin (or package, if necessary) for Visual Studio 2005 that needs watch window type functionality -- evaluation of expressions and examination of the types. The automation facilities provide
Debugger::GetExpression, which is useful enough, but the information
provided is a bit crude.
From looking through the docs, it sounds like an
IDebugExpressionContext2 would be more useful. With one of these it
looks as if I can get more information from an expression -- detailed
information about the type and any members and so on and so forth, without having everything come through as strings.
I can't find any way of actually getting a IDebugExpressionContext2,
though! IDebugProgramProvider2 sort of looks relevant, in that I
could start with IDebugProgramProvider2::GetProviderProcessData and
then slowly drill down until reaching something that can supply my
expression context -- but I'll need to supply a port to this, and it's
not clear how to retrieve the port corresponding to the current debug
session. (Even if I tried every port, it's not obvious how to tell
which port is the right one...)
I'm becoming suspicious that this simply isn't a supported use case, but with any luck I've simply missed something crashingly obvious.
Can anybody help?
By using IDebugExpressionContext you'll ultamitely end up getting ahold of an instance of IDebugProperty. This interface is implemented by the Expression Evaluator service. This is, typically, a language specific service. It's designed to abstract out the language specific details of evaluating an expression. It understands much higher level commands like "Evaluate", and inspection.
I don't think you're going to get what you're looking for though because you can't get ahold of any kind of type object this way. Nearly all of the inspection methods return their results in String form. For example you won't get the type Int32 but instead the string "int". This makes type inspection next to impossible.
I don't believe what you're trying is a supported case. The type system being evaluated doesn't exist in the current process. It exists in the debuggee process and is fairly difficult to get access to.
There's a hack you could do to get more information about the type of a variable you've evaluated using Debugger::GetExpression method.
You could evaluate "AppDomain.CurrentDomain.GetAssemblies()" to get all the assemblies loaded into the debugee, and cache them in your add-in. You may also need to listen for new assemblies being loaded onto the AppDomain.
Then, run the following:
Expression myExpression = Debugger.GetExpression(...);
Expression typeRefExpression = Debugger.GetExpression("typeof(" + myExpression.Type + ").FullName"
once you have the TypeFullName, you can search inside your assemblies cache for a matching System.Type, and once you have that, you can dig into it all you want using the standart Reflection API.
Note that this will only work in C#, because of its "typeof" keyword. You'll have to use a different keyword for VB.Net, for example.
In response to a previous question on how to achieve a certain effect with Swing, I was directed to JDesktopPane and JInternalFrame. Unfortunately, scala.swing doesn't seem to have any wrapper for either class, so I'm left with extending it.
What do I have to know and do to make minimally usable wrappers for these classes, to be used with and by scala.swing, and what would be the additional steps to make most of them?
Edit:
As suggested by someone, let me explain the effect I intend to achieve. My program controls (personal) lottery bets. So I have a number of different tickets, each of which can have a number of different bets, and varying validities.
The idea is displaying each of these tickets in a separate "space", and the JInternalFrames seems to be just what I want, and letting people create new tickets, load them from files, save them to files, and generally checking or editing the information in each.
Besides that, there needs to be a space to display the lottery results, and I intend to evolve the program to be able to control collective bets -- who contributed with how much, and how any winning should be split. I haven't considered the interface for that yet.
Please note that:
I can't "just use" the Java classes, and still take full advantage of Scala swing features. The answers in the previous question already tell me how to do what I want with the Java classes, and that is not what I'm asking here.
Reading the source code of existing scala.swing classes to learn how to do it is the work I'm trying to avoid with this question.
You might consider Scala's "implicit conversions" mechanism. You could do something like this:
implicit def enrichJInternalFrame(ji : JInternalFrame) =
new RichJInternalFrame(ji)
You now define a class RichJInternalFrame() which takes a JInternalFrame, and has whatever methods you'd like to extend JInternalFrame with, eg:
class RichJInternalFrame(wrapped : JInternalFrame) {
def showThis = {
wrapped.show()
}
}
This creates a new method showThis which just calls show on the JInternalFrame. You could now call this method on a JInternalFrame:
val jif = new JInternalFrame()
println(jif.showThis);
Scala will automatically convert jif into a RichJInternalFrame and let you call this method on it.
You can import all java libraries directly into your scala code.
Try the scala tutorial section: "interaction with Java".
Java in scala
You might be be able to use the scala.swing source as reference e.g. http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk/src/swing/scala/swing/Button.scala
What sort of scala features are you trying to use with it? That might help in coming up with with an answer. I.e. - what is it you're trying to do with it, potentially in Java? Then we can try to come up with a nicer way to do it with Scala and/or create a wrapper for the classes which would make what you're trying to do even easier.
In JRuby, you could mix in one (or more) traits into JDesktopPane or JInternalFrame instead of extending them. This way you wouldn't have to wrap the classes but just use the existing objects. As far as I know, this is not possible with Scala traits.
Luckily, there is a solution, almost as flexible as Ruby's: lexically open classes. This blog article gives an excellent introduction, IMHO.