Did I miss a point in this thread where using a typeclass/trait to
implement exponentiation was dismissed?
This function could be changed to:
fn pow<T: HasPow>(base: T, exp: uint) -> T { base.pow(exp) }
trait HasPow {
fn pow(self: Self, exp: uint) -> Self
}
Or, just use HasPow in your code.
Why is this not a solution?
On Fri, Jul 25, 2014 at 6:53 AM, Christoph Husse <
thesaint1...@googlemail.com> wrote:
> Sorry... I meant a^8 xD...
>
> And overlaoding is not a great concept in general, IMO.
> What Rust could do is copy template specialization. So that I can say:
>
> pub fn pow<T: One + Mul<T, T>>(mut base: T, mut exp: uint) -> T; //
> uses the exponential trick
>
> pub fn pow<i64>(mut base: i64, mut exp: uint) -> i64; // uses some
> cool processor features if available
>
> pub fn pow<BigInt>(mut base: &BigInt, mut exp: uint) -> BigInt; //
> uses some mighty algorithm that is not naive ;)
>
> This avoids the horrible confusing of having functions acting totally
> different depending on parameter count. Of course there should still
> be the requirement in place that all specializations fulfill the
> original template contraints. And in the best case also need to
> fullfill some generic unitests that give a specification to ensure
> that the user is not confused by this sort of "overloading".
>
>
> On Fri, Jul 25, 2014 at 6:47 PM, Christoph Husse
> <thesaint1...@googlemail.com> wrote:
> >> I gave up at all. (I'm doing software design and implementation since
> >> more than 30 years, and I never accept compromises, this is the way
> >> how to develop magnificient software).
> >
> > Hum, I would almost strongly disagree. I would even go as far as
> > saying that you won't develop any kind of reasonable software outside
> > of academic environments without making a whole fairytale of
> > compromises. In fact, everything is a compromise. Besides that, giving
> > up just because you can't overload functions, in a language that is
> > still evolving also sounds rather strange. More legit would be to
> > mention the issue, ask how the designers of the language would solve
> > it and maybe suggest what could be improved etc...
> >
> >> the big integer libary because I cannot specialize std::num::pow().
> There is
> >> no way to proceed with a proper design.
> >
> > Well, I guess you did nothing but C++ in the last 30 years then?
> > Because I can't recall many languages that would allow this sort of
> > thing. How would C# and Java's Math::Pow() would work out in this
> > case? How would it work out in C? How would it work out in Python,
> > JavaScript, etc... the list is ... quite long.
> >
> > The question is always about compromise. Shall rust include a language
> > feature to make some things easier for the sake of introducing tons of
> > problems as well?
> > Java is about the least expressive language we have at the time
> > (appears a bit like the greatest common denominator of all imperative
> > languages) and I would say only few people are out there who would say
> > that you can't do proper software design with it. It might not be a
> > concise and pleasing as "GOOD C++ design is", but then again "GOOD C++
> > design" is very hard to archieve and thus begs the questions if it is
> > even worth it to make a language that complicated so that magnificient
> > (academic) design is possible at the cost of making the average
> > (industrial) design horrible.
> >
> >> pub fn pow<T: One + Mul<T, T>>(mut base: T, mut exp: uint) -> T;
> >
> > I agree this definition appears to be very strange to me. In more than
> > one way. First it implies that the existing implementation works by
> > somehow multiplying types with the expontential trick " a * a = b, b *
> > b = c, c * c = a^6" etc...
> > This is an unacceptable restriction for me, as this kind of evaluation
> > might not be the best in many cases and we are talking about a
> > standard library function after all. It should always allow the BEST
> > implementation, not just some implementation.
> >
> > Here we clearly need a better concept. And this concept needs to be
> > designed & defined. And you could start by doing this, instead of just
> > giving up ;).
> _______________________________________________
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
--
Oscar Boykin :: @posco :: http://twitter.com/posco
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
