On Feb 22, 6:20 am, Bill Kelly <bi... / cts.com> wrote:
> From: "Rule.rule" <rule.rule.r... / gmail.com>
>
>
>
>
>
> > On Feb 22, 2:08 am, Bill Kelly <bi... / cts.com> wrote:
>
> >> Anyway -Rubyhas strong/dynamic typing
>
> > Dynamic, sure.
> > But re strongly, yes, I have seen this claim in several places
> > (including from Matz).
> > As I pointed out on wiki, though, it seems to depend on what
> > definition one refers to.
> > It seems to me, Matz is using Defs #3 and/or #6 in the list I gave
> > there:
> >    http://en.wikipedia.org/wiki/Ruby_%28programming_language%29
>
> > ButRubyimmediately clashes with my own "intuitive concept" of
> > "strongly typed",
> > when you can do things like:
> >  x = 2; x = "a"
> > without getting an error,
> > and you also have untyped lists/arrays, etc, in the language.
>
> OK; well... the closest to what I had in mind appears to be #6.
> However, the caveat warning that #6 is difficult to prove
> mathematically seems spurious to me.
>
> If one can writerubycode that evadesruby'stype system, it's
> a bug in the language implementation.  So it's like having a caveat
> for C++ that says, the compiler is supposed to generate valid
> assembly code for all valid input statements, but this is very
> difficult to prove mathematically. . . . Yes, it may be difficult
> to prove that there are no implementation bugs in C++ compilers,
> but we don't go around adding asterisks to that effect when
> talking about C++.
>
> InRuby, an object's type is essentially related to which set
> of messages that object responds to at any given point in time.
> Classes, inRubyare more useful for implementation inheritance,
> than in establishing an object's type.  Rubyis much more dynamic
> than that; a given object need not necessarily respond to all
> the methods provided by its superclass (it could undefine some
> or all of those methods, for example.)
>
> InRuby, variables don't have types, objects do.  And an object's
> type cannot necessarily be usefully determined by looking at
> the object class's inheritance hierarchy.  Nonetheless, one
> cannot evadeRuby'stype system as one can in C++:
>
>   class Dog { public: void bark(); };
>   class Cat { public: void meow(); };
>   Dog *dog = new Dog();
>   ((Cat *) dog)->meow();
>
> In C++, the above results in undefined behavior. (Possibly crash.)
> The equivalent inRubydoes NOT result in undefined behavior.
>
>   class Dog; def bark; puts "Woof!"; end; end
>   class Cat; def meow; puts "Mew!"; end; end
>
>   cat = Dog.new
>   cat.meow
>
>   NoMethodError: undefined method `meow' for #<Dog:0x2c6cf40>
>
> InRuby, we have merely tried to send an object a message it
> doesn't respond to.  That is a perfectly well-defined scenario
> in the language, and the type system has not been violated or
> evaded.
>
> If it helps clarify, the following statements:
>
>   cat = Dog.new
>   cat.meow
>
> ..are semantically equivalent to:
>
>   some_object = Dog.new
>   some_object.send(:meow)
>
> ..In the latter, it should be clear that we are merely
> attempting to send an object referenced by the variable
> <some_object> a particular message, :meow.
>
> Ultimately, it's really a fairly elegant and beautiful and
> simple type system: Messages are sent to objects, which either
> respond to them or they don't.
>
> Sadly, I'm no math whiz - but "objects respond to messages or
> they don't" doesn't strike me as likely to be as hard to
> prove mathematically as #6 on the wiki page tries to claim.
>
> One more example...
>
> What should we call the 'type' of the following object?
>
> >> class Psychotic
> >>   def method_missing(name, *args)
> >>     if name.to_s.length == 6
> >>       raise(NoMethodError, "I don't like six-letter method names, such as #{name}!")
> >>     else
> >>       puts "Awesome! I'm so happy you called my method #{name} !"
> >>     end
> >>   end
> >> end
> >> x = Psychotic.new
>
> => #<Psychotic:0x279af38>
>
> Here, we have an object that will happily respond to ANY method
> called on it...
>
> >> x.hello
>
> Awesome! I'm so happy you called my method hello !>> x.lets_be_friends
>
> Awesome! I'm so happy you called my method lets_be_friends !>> x + x
>
> Awesome! I'm so happy you called my method + !
>
> ..EXCEPT methods of exactly six letters:
>
> >> x.hooray
>
> NoMethodError: I don't like six-letter method names, such as hooray!
>         from (irb):46:in `method_missing'
>         from (irb):55
>         from :0
>
> What is the type of that object?  (I'm not sure what to call its type,
> but nevertheless its type still can't be disabled or evaded!)
>
> Welcome toRuby.  <grin>
>
> >> But static typing is not required for "real-life" development.  :)
>
> > Obviously not, I have also seen a few sizable systems entirely built
> > in PHP or Perl or whatever,
> > after they started out as a "pilot" and later they didnt have the
> > funds to rebuild them,
> > decided to go live with what they had, and kept expanding on it...
>
> > But how easy and fun are they to maintain and extend, when over the
> > years the
> > original creators leave the project and new people join, etc?
>
> In 2.5 decades of programming so far, the two worst codebases
> I've had to maintain so far were in C, and Java.  I wouldn't
> blame that language for that, just the coders.
>
> Regards,
>
> Bill

Thank you very much, Bill.
Most worthwhile input, and just the kind of feedback I was hoping for
when I started this thread  :)

Anyways, I think I had a realization here -- that a type-identifier in
any earlier language I have seen, are considered to be a Constant.
Once it's defined, it's defined and doesn't change.
While a type-identifier (or class-identifier) in Ruby should rather be
looked upon as a Variable.
Just as an ordinary variable, it can mean different things in
different places within a scope (or even within an expression, I
guess).

That is certainly a new dimension, and obviously would require quite
different frameworks for mathematical/logical analysis, for example.

As a trivial example,
if you have a function F that takes an argument of type A and returns
a result of type A,
well, actually the type A may have changed between the point of
invocation of the function and the point where the result is returned.

Hmmm... by meta-programming, actually, the function F may also have
changed during the call, I guess...
OK, will digest this for a while... :)

Best regards,