On Mon, 27 Jan 2014 14:34:30 -0000, Dicebot <[email protected]> wrote:
On Monday, 27 January 2014 at 14:27:42 UTC, Regan Heath wrote:
On Sat, 25 Jan 2014 10:15:28 -0000, Peter Alexander
<[email protected]> wrote:
Special cases are pure evil. There's nothing special about strings in
this case.
This is a tangent to my suggestion.
I am arguing for domain specific language (aliases) where sensible, not
domain specific functions. If canFind can already handle all the
desirable string cases, perfect, but lets alias it in std.string as
"contains" so that people find what they expect to find first time and
don't get frustrated looking for the correct generic name for the
functionality they want.
There are likely other cases where we already have all the
functionality in a nice generic function, but people struggle to find
it because it has a suitably generic name.
I just want us to lower the bar for beginners coming from other
languages like Java and C#.
R
I think that is a small short-term learning advantage but huge long-term
damage for code readability. Now you suddenly need to not only remember
what Phobos can do but also all defined aliases for that stuff.
No, you really don't.
If you're writing string code you will intuitively reach for "substring",
"contains", etc because you already know these terms and what behaviour to
expect from them. In a generic context, or a range context you will reach
for different generic or range type names.
Likewise when reading code you will read "contains" and immediately know
what it does, you don't need to remember that it's also called canFind ..
why would you care?
Even *if* you decided to compare some string code with some generic code,
and the two were actually doing the "same" thing with different calls, you
wouldn't have any trouble at all in understanding each and then realising
they do the same thing.
What could have been awesome is to be able to define such aliases via
DDOC so that IDE's can understand them and list in auto-completion,
while still putting "real" name in source code. It would have solved
discoverability issue without harming naming consistency.
I think I would dislike this.. not sure. Do our docs have "synonyms" in
function descriptions.. then at least google would find "contains" on the
page next to canFind and you would have an answer.
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
