3 Replies - 1901 Views - Last Post: 08 November 2012 - 05:39 AM Rate Topic: -----

#1 Static Hazard  Icon User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 49
  • Joined: 25-November 09

Conceptual question regarding Ruby types

Posted 07 November 2012 - 09:07 PM

Okay, I have an assumption that I'd like to be confirmed (or corrected) by you Ruby pros.

I am looking at how Java types are stored vs. Ruby types. I know that Java is a strongly typed language, where you have to explicitly state a type for each value. Ruby, on the other hand (to my knowledge), is implemented at its foundation in C, and to contrast, is dynamically typed, so you don't have to declare a type, the interpreter figures it out for you. This difference is important because Java is prone to type confusion, which can be bad. However, because Ruby's values are dynamic, does that make it "invincible" to these type confusions?

If you don't know about type confusion in Java, here is a really brief and helpful article: http://www.securingj...ter-five-7.html

This post has been edited by Static Hazard: 07 November 2012 - 09:08 PM


Is This A Good Question/Topic? 0
  • +

Replies To: Conceptual question regarding Ruby types

#2 xclite  Icon User is offline

  • LIKE A BOSS
  • member icon


Reputation: 877
  • View blog
  • Posts: 3,122
  • Joined: 12-May 09

Re: Conceptual question regarding Ruby types

Posted 07 November 2012 - 09:11 PM

You may want to look into "duck typing" to answer your question. Dynamic languages aren't "immune" to typing issues - the wrong structure or item can still be passed in at the wrong time. A disadvantage is that these mistakes are found at runtime rather than compiletime.

On the other hand, these systems are much more flexible - in Ruby, I often only care that my argument "responds" to a specific message, rather than that it implements a certain type. This allows some powerful mixin capabilities. For one example of this, check out what you get for implementing each and <=>:
http://ruby.about.co...able-Module.htm
Was This Post Helpful? 2
  • +
  • -

#3 Static Hazard  Icon User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 49
  • Joined: 25-November 09

Re: Conceptual question regarding Ruby types

Posted 07 November 2012 - 09:20 PM

I will definitely look into that! Thanks
Was This Post Helpful? 0
  • +
  • -

#4 sepp2k  Icon User is online

  • D.I.C Lover
  • member icon

Reputation: 2013
  • View blog
  • Posts: 3,038
  • Joined: 21-June 11

Re: Conceptual question regarding Ruby types

Posted 08 November 2012 - 05:39 AM

A note on terminology and typing: Strong typing isn't really a well-defined term, but it usually does not mean that each variable has to be annotated with a type. In my experience it's most commonly used to mean that when types are used together in an incompatible way, this will lead to a type error - as opposed to a weakly typed language where the language will try to find a way to execute the action anyway (using implicit conversions for example). By that definition both Ruby and Java are strongly typed (and e.g. Perl and C are not).

What you meant is static typing. A statically typed language is one where (most) type errors can be detected before the program runs and a program that contains type errors will not run at all. So in a dynamically typed language the following code would print "Hello" and then crash with a type error because you can't divide a string by a number, while in a statically typed language it would cause a type error and never print anything:

print("Hello")
print("42"/2)



In the weakly-typed language Perl the above code would print "Hello21" and not cause a type error at all.

Note that while statically typed languages often do require type annotations, that itself is not the definition of a statically typed language and there are statically typed languages where type annotations are optional or don't exist at all. In those languages the types of variables will be inferred statically and can thus still be checked without running the code.

There are even dynamically typed languages with type annotations where the type annotations are only checked at run time.
Was This Post Helpful? 1
  • +
  • -

Page 1 of 1