What's the Difference Between Ruby Core API and Standard Library API

What's the difference between Ruby Core API and Standard Library API?

Yep, you got it right. Core functionality is everything you don't have to require to use.

DateTime seems to be not in the core (are you running your line inside of rails console, maybe?)

DateTime.now # => 
# ~> -:1:in `<main>': uninitialized constant DateTime (NameError)

But Time is

Time # => Time
Time.now # => 2013-08-29 12:32:54 +0400

Only a few methods of Time are in core, though. To get more functionality (like Time.parse) you have to

require 'time'

Standard Library Reference for Ruby

There is the Ruby Standard Library documentation and sites like apidock. The Pickaxe book has a great reference towards the end. There's even a free version online, but it's quite out of date; to find the reference there, click Standard Library in the top-left frame.

What is Ruby 1.9 standard CSV library?

Ruby 1.9 has adopted FasterCSV as its built-in CSV library. However, it's in the standard library rather than Ruby 1.9's core, so you need to manually require it in your application.

After adding a

require 'csv'

to your code, you can then do things such as

CSV.parse("this,is,my,data")

See Ruby 1.9's standard library CSV documentation for information on using the library.

What exactly is the meaning of an API?

Searches should include Wikipedia, which is surprisingly good for a number of programming concepts/terms such as Application Programming Interface:

What is an API?

An application programming interface (API) is a particular set of rules ('code') and specifications that software programs can follow to communicate with each other. It serves as an interface between different software programs and facilitates their interaction, similar to the way the user interface facilitates interaction between humans and computers.

How is it used?

The same way any set of rules are used.

When and where is it used?

Depends upon realm and API, naturally. Consider these:

1. The x86 (IA-32) Instruction Set (very useful ;-)
2. A BIOS interrupt call
3. OpenGL which is often exposed as a C library
4. Core Windows system calls: WinAPI
5. The Classes and Methods in Ruby's core library
6. The Document Object Model exposed by browsers to JavaScript
7. Web services, such as those provided by Facebook's Graph API
8. An implementation of a protocol such as JNI in Java

Happy coding.

What is the difference between a class library and a framework

The distinguishing feature between a class library and a software framework is that in a framework, the flow of control is not determined by the user´s code, but by the framework.

This is also known as Hollywood principle (don´t call us, we call you).

By the way, there is also a nice Wikipedia article on this topic.

What is the difference between as_json vs JSON.parse?

The two methods are in some sense exact opposites of each other:

• JSON.parse parses a Ruby String containing a JSON Document into a Ruby object corresponding to the JSON Value described by the JSON document. So, it goes from JSON to Ruby.
• as_json returns a simplified representation of a complex Ruby object that uses only Ruby types that can be easily represented as JSON Values. In other words, it turns an arbitrarily complex Ruby object into a Ruby object that uses only Hash, Array, String, Integer, Float, true, false, and nil which correspond to the JSON types object (really a dictionary), array, string, number, boolean, and null. The intent is that you can then easily serialize this simplified representation to JSON. So, as_json goes from Ruby (halfway) to JSON. In other words, the opposite direction from JSON.parse.

Apart from operating in opposite directions, there are some minor other differences as well:

• JSON.parse is a concrete method, whereas as_json is an abstract protocol that is implemented by many different kinds of objects. (Similar to e.g. each in Ruby).
• JSON.parse is part of the Ruby standard library (but not the core library, more precisely, it is part of the json gem, which is a default gem). The as_json protocol is defined by ActiveRecord's Serializers API, i.e. it is part of ActiveRecord, not Ruby.

So, why does as_json exist in the first place? Why this two-step process of converting complex Ruby objects to simpler Ruby objects and then to a JSON Document instead of going straight from complex Ruby objects to a JSON Document? Well, if you have complex Ruby objects, chances are, that no object actually fully knows how to serialize itself as a JSON Document. It has to first ask its constituent objects to serialize themselves, and then stitch it all together, and this applies recursively to the constituent objects as well. With all this stitching together of JSON Documents, there is a real risk of producing an invalid JSON Document or double-encoding some part of it, or something along that lines.

Basically, once you have serialized something to a JSON Document, then all you have is a String and all you can do is String manipulation. Whereas, if you have a richer Ruby object like Hash, Array, Integer, etc., then you can use that object's methods as well. Imagine, for example, having to merge two JSON Documents containing JSON Objects as a String compared to simply merging two Ruby Hashes.

So, the idea is to use as_json first to create a Ruby object that is simpler and less powerful than the original, but still much more powerful than a simple String. And only once you have assembled the entire thing, do you use to_json to serialize it to a JSON Document. (Or rather, the serialization framework does that for you.)

Why do you need to use require for the Set class?

Unlike the core modules, the modules in Ruby's standard library are not loaded by default. This is to minimize Ruby's memory footprint at runtime. Basically, if it's not in here http://ruby-doc.org/core-2.3.0/, then it needs to be required at runtime.

---

Related Topics