[ruby-talk:9857] Re: 101 Misconceptions About Dynamic Languages

Christoph Rippel <[e-mail]> wrote:
>"Josh Stern" <[e-mail]> wrote in message
>news:3a6f3d73$0$26803$[e-mail]...
>[..]
>>
>> Reimer, you misunderstood the pragmatics of my post.
>
>Talking about misunderstanding. I  am the person who initiated
>the sup-thread about generic programming never indicated that
>there are issues about type safety or overloading with respect to
>the IMO problematic support for generic programming.

I wasn't really thinking of one person.
You expressed the idea that it is hard to
cleanly do real generic programming (or some species thereof) 
in Ruby,  
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/9691

and jmichel made the specific link to overloading here:
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/9710

Type safety was in an unrelated part of the thread and nobody
has mentioned it recently.

>> It had previously  been asserted in the discussion that
>> Ruby would have trouble with full blown generic programming
>> because of the lack of overloading and automatic instantiation
> > of overloaded functions for the generic parameters.  There had

>My beef with ruby that there doesn't exist a good infrastructure
>to facilitate  automatic  instantiation of generic parameters
>and I still hold this opinion.

Are you talking about a shortcut, in the sense that accessor
functions are shortcuts, or are you talking about something
that is really hard to do?

>However the mixin mechanism and the C++-template are conceptually
>fairly close, see for example my incoherent  ramblings  [ruby-talk:8174]

?? This is what I see as ruby-talk 8174 
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/8174

I think from context below that you must mean 9764

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/9764

Almost all of Ruby is similar in one sense to C++ template function
definitions because it selects methods and types by name rather than 
reference.  That is part of the appeal for C++ guys.  Mixins 
have the extra feature of being similar to template classes 
because they provide data members and methods with common names,
while encapsulating most of the code in one place.

>on the  subject, but the current mixin mechanism does not come with built
>in support of instantiation of Module constants  at ``include time''
>(i.e. instantiation of generic parameters)   to be able mine this analogy.
>(My generic prototype provides a quick  and incomplete fix )

Ok. But I think to do full blown genericity, where, the module
actually has different data vars and methods (in name and numerosity)
based on the generic parameters, one would do meta-programming in Ruby
in place of partial specialization in C++.

>> I wasn't advocating that.  Though I have suggested in other posts
>> that overloading would be useful in Ruby, but for somewhat different
>> reasons.
>
>Belatedly responding to your explanation of  ``Koeniging'' - it seems to
>me that a Ruby implementation of overloading wouldn't need to rely on such
>facility since it is mainly used to resolve naming ambiguities resulting
>from
>of compile time versus runtime issues - which for obvious reason would not
>exist in Ruby  but I might be a bit blue-eyed about this.

Method definition time in Ruby is a partial analog of compile time.
If a method calls method1 and method2 of its argument, and, for instance,
no currently defined class has methods of both those names,
this might be a good thing to catch, where possible. 
Also, somebody might write something like:

if obj.class == SomeClass1

elseif obj.class == SomeClass2

...

else
  raise "Shouldn't get here"
end

and it would be nice, where possible, to know if current code
is gunning for an exception.  The complexity of getting these
things right surely increases with the number of arguments
to the method, the length of time since it was written,
and the possibility that there original author was somebody
different than the maintainer.  It is true that interpreted
solutions wouldn't have the run-time efficiency gain of
resolving most all type ambiguity at compile time.

-= Josh