Is this still relevant? http://www.fandev.org/sidewalk/topic/16 Because I kinda like method overloading. I mean, in my case I can work around it, but having to differentiate by method name isn't quite as clean as overloading. But seeing as how that post was 3 years ago, i thought I'd check. It seems to still be true, though.
tompalmerThu 26 Feb 2009
I still strongly prefer against overloading (except perhaps for operators). Just my own opinion.
otomodachiThu 26 Feb 2009
I think that multiple dispatching (aka multimethods) solves a wider range of problems.
cheeserThu 26 Feb 2009
Have an example of that? I'm not opposed to learning new idioms as long as I can read up on them and I've been doing solely java long enough to have developed some hardened habits. Some reading material would be fantastic...
tompalmerFri 27 Feb 2009
In the abstract sense, multimethods seem nice. I've never used them, so I can't say in practice. I doubt they are the right choice for Fan, but I could be wrong.
tompalmerFri 27 Feb 2009
By the way, I haven't looked up readings, but multimethods are where all argument types are used when looking up a method, not just the object you call the method on. And that's the runtime type (i.e., possibly a subtype), not the statically visible type. Being too quick to give an actual example, sorry.
Is this still relevant? http://www.fandev.org/sidewalk/topic/16 Because I kinda like method overloading.
It is definitely still relevant. The fact that Fan doesn't permit parameter based overloading of methods is a feature. I agree sometimes it can be a drag, but with default parameters I find it hardly ever comes up.
The huge benefit is that all slots can be referenced strictly be name. If you ever tried to do reflective or meta-programming in Java you know what a huge mess this is. The fact that a name has a single mapping to a slot is extremely powerful. For example how would you do slot literals if a name potentially mapped to multiple methods? Think about how much slower dynamic invoke has to become? Imagine all the evil ways that features like currying would interact with method overloads?
So anyways, hopefully you can appreciate that by giving up overloading, we gain a whole lot of other cool things in return.
freddy33Thu 5 Mar 2009
I personally think that no methods/fields overloading is one of the best feature of Fan :)
cheeser Thu 26 Feb 2009
Is this still relevant? http://www.fandev.org/sidewalk/topic/16 Because I kinda like method overloading. I mean, in my case I can work around it, but having to differentiate by method name isn't quite as clean as overloading. But seeing as how that post was 3 years ago, i thought I'd check. It seems to still be true, though.
tompalmer Thu 26 Feb 2009
I still strongly prefer against overloading (except perhaps for operators). Just my own opinion.
otomodachi Thu 26 Feb 2009
I think that multiple dispatching (aka multimethods) solves a wider range of problems.
cheeser Thu 26 Feb 2009
Have an example of that? I'm not opposed to learning new idioms as long as I can read up on them and I've been doing solely java long enough to have developed some hardened habits. Some reading material would be fantastic...
tompalmer Fri 27 Feb 2009
In the abstract sense, multimethods seem nice. I've never used them, so I can't say in practice. I doubt they are the right choice for Fan, but I could be wrong.
tompalmer Fri 27 Feb 2009
By the way, I haven't looked up readings, but multimethods are where all argument types are used when looking up a method, not just the object you call the method on. And that's the runtime type (i.e., possibly a subtype), not the statically visible type. Being too quick to give an actual example, sorry.
otomodachi Fri 27 Feb 2009
^_^ Some reading:
What's your opinion on multimethods?
brian Fri 27 Feb 2009
It is definitely still relevant. The fact that Fan doesn't permit parameter based overloading of methods is a feature. I agree sometimes it can be a drag, but with default parameters I find it hardly ever comes up.
The huge benefit is that all slots can be referenced strictly be name. If you ever tried to do reflective or meta-programming in Java you know what a huge mess this is. The fact that a name has a single mapping to a slot is extremely powerful. For example how would you do slot literals if a name potentially mapped to multiple methods? Think about how much slower dynamic invoke has to become? Imagine all the evil ways that features like currying would interact with method overloads?
So anyways, hopefully you can appreciate that by giving up overloading, we gain a whole lot of other cool things in return.
freddy33 Thu 5 Mar 2009
I personally think that no methods/fields overloading is one of the best feature of Fan :)