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

"Josh Stern" <[e-mail]> wrote in message
news:3a6feb47$0$26813$[e-mail]...
[...]
> 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?

I am talking about shortcuts.

> >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 throw this in because of the specialisation  analogy.
> 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++.
Yes  C++- meta templates are some what different. The intended use  of
``#generic_bucket''   was that you can pre -process data and based
on this information  ``parametrically include'' a couple of them (which
modules you include might  depend on the data,for example some of
them may only contain a bunch of  ``attributes'' etc.).  The  constants
could be  classes,methods,procs your even arrays of the things.  Note
some effect of traits can be achieved by changing method in the base
class|modules or overriding of an already instantiated Class.

If want to go beyond this the first thing coming to my mine
mind are generative  patters which would involve the use of yield
and recursion and since Ruby is not a functional style language
(with bad syntax) the analogy to  C++ templates obviously
breaks down.

For example if you wrote your  (one dimensional) Poly
generator  you can  write your multi-dim Poly generator (for
many purposes the result won't be particularly efficient )

class GenRing
def Poly ring
     #
end
def Mpoly ring ,n
      res = ring
       n.times { | i|      res  =  Poly  res }
       res
 end
 ...
end

[..]
> 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.
My thinking is that it might be a good idea to write something like
class MethodProperties
 #  nice interface to define method signature
# maybe define other things like lazy evaluation
# trusted? - tainted? ...
end
An Object of class MethodProperties could be feed into interpreter
with some syntax at function definition time but I am not really sure.
> -= Josh
>

Christoph