I have a function that does some weird stuff, and can't really change it to make life easier(due to how windows work, COM, etc..).

The function normally takes a string, a name, and does its think(which is the complex part that I can't change).

But I also want to overload it so the function takes an int. I can't simply overload the function and call the string version or vice versa as one would normally do because this would require initializing twice, which can't happen because the way the code works.

The int value is a lookup into an array, and the name version searches the array for a name match. I can't overload the int version and search the name first because the data doesn't exist yet

void Do(string name)
{
    // get index of name in array
    // can't find x corresponding to name because data is not initialized.
    // Can't init data more than once. Can't add init flag(could but want to find a better solution)
    Do(x);
}

void Do(int index)
{
    Init_Data();
    ...
}



Now, I could simply make Do a template method but then this prevents it being a virtual function.

void Do(T)(T name) if (is(T == string) || is(T == int))
{
    Init_Data();

    static if (is(T == string))
    {
        ...Get index from name
    }

    ....
}



What I really want is a sort of mix between the first overloaded method and the second case.


The string version is really just finding the index of the string and should insert itself inside the int version similar to the static if.

I know there are many ways and many are going to fuss over doing it with a bool or duplicate the function or whatever. I'm looking for an elegant solution for what I want, I know there are other ways... not interested in them. Given that D has so many meta capabilities, I'm hoping there is some elegant solution.

To make it clear.

void Do(int index)
{
   // Does stuff

    // If index was a string instead of a name, we would do a lookup to find the index for name. Everything else is exactly the same

   // does stuff with index
}

void Do(string name)
{
    // somehow
    Do(name_index);
}


Another way is to use a lambda:

void Do(int index, int delegate(data) toName)
{
    // Does stuff
    if (toName) index = toName(data);
    // Do stuff with index
}

void Do(string name)
{
    Do(0, (data) { find i for name; return i; });
    // which plugs in the lambda
}



The problem with all these ways is that they complicate matters and either duplicate a lot of code or create hard to maintain code or problems in other areas. e.g., if I use the template method any literal string is not automatically converted do("this won't be treated as a wstring").

If a bool is used, I have to have the initialization code in both functions. Doesn't seam like much until you scale the problem up.

What would be nice is something akin to yield:

void Do(int index)
{
    // Does stuff
    ?yield // If Do is called in a special way, we break out of the code here
    // Do stuff with index
}

void Do(string name)
{

    yield Do(0);
    find i for name;
    continue Do(i);
}


This keeps everything internal and from the outside everything looks as it should, avoids duplicate code, extra arguments, flags, etc.

Is it possible?

Extract functions for shared parts:

void Do(string name)
{
    DoStuff();
    int i = find(name);
    DoStuffWithIndex(i);
}

void Do(int name)
{
    DoStuff();
    DoStuffWithIndex(i);
}

On Tuesday, 12 July 2016 at 08:52:26 UTC, Kagamin wrote:
> Extract functions for shared parts:
>
> void Do(string name)
> {
>     DoStuff();
>     int i = find(name);
>     DoStuffWithIndex(i);
> }
>
> void Do(int name)
> {
>     DoStuff();
>     DoStuffWithIndex(i);
> }

I don't like it, creates an extra function for no apparent reason except to get around the problem of not having a yield type of semantic. Again, I wasn't asking for any ol' solution, there are many ways to skin this cat.

On Tuesday, 12 July 2016 at 13:44:02 UTC, Adam Sansier wrote:
> On Tuesday, 12 July 2016 at 08:52:26 UTC, Kagamin wrote:
>> Extract functions for shared parts:
>>
>> void Do(string name)
>> {
>>     DoStuff();
>>     int i = find(name);
>>     DoStuffWithIndex(i);
>> }
>>
>> void Do(int name)
>> {
>>     DoStuff();
>>     DoStuffWithIndex(i);
>> }
>
> I don't like it, creates an extra function for no apparent reason except to get around the problem of not having a yield type of semantic. Again, I wasn't asking for any ol' solution, there are many ways to skin this cat.

It is usually considered a good thing to break big functions into smaller ones; this allows for easier code reading, better maintainability and easier reuse.
Also note that yield semantics as available in various languages is much different from what you are proposing here.

On Tuesday, 12 July 2016 at 13:44:02 UTC, Adam Sansier wrote:
> I don't like it, creates an extra function for no apparent reason except to get around the problem of not having a yield type of semantic. Again, I wasn't asking for any ol' solution, there are many ways to skin this cat.

It's a normal use case for private functions: the public function prepares object state and delegates to the private function that does the logic.

On Tuesday, 12 July 2016 at 13:54:16 UTC, Lodovico Giaretta wrote:
> On Tuesday, 12 July 2016 at 13:44:02 UTC, Adam Sansier wrote:
>> On Tuesday, 12 July 2016 at 08:52:26 UTC, Kagamin wrote:
>>> Extract functions for shared parts:
>>>
>>> void Do(string name)
>>> {
>>>     DoStuff();
>>>     int i = find(name);
>>>     DoStuffWithIndex(i);
>>> }
>>>
>>> void Do(int name)
>>> {
>>>     DoStuff();
>>>     DoStuffWithIndex(i);
>>> }
>>
>> I don't like it, creates an extra function for no apparent reason except to get around the problem of not having a yield type of semantic. Again, I wasn't asking for any ol' solution, there are many ways to skin this cat.
>
> It is usually considered a good thing to break big functions into smaller ones; this allows for easier code reading, better maintainability and easier reuse.

Doesn't matter, that isn't what I asked.

> Also note that yield semantics as available in various languages is much different from what you are proposing here.

Not really. Yield is usually a break in flow, regardless just because it's applied to fibers doesn't mean it's *much* different. It's the same basic concept.

On Tuesday, 12 July 2016 at 16:03:15 UTC, Kagamin wrote:
> On Tuesday, 12 July 2016 at 13:44:02 UTC, Adam Sansier wrote:
>> I don't like it, creates an extra function for no apparent reason except to get around the problem of not having a yield type of semantic. Again, I wasn't asking for any ol' solution, there are many ways to skin this cat.
>
> It's a normal use case for private functions: the public function prepares object state and delegates to the private function that does the logic.

Doesn't matter, it's not what I asked. Trying to provide answers to a question that wasn't asked and was clearly stated I wasn't interested in those types of answers.

On Tuesday, 12 July 2016 at 16:30:05 UTC, Adam Sansier wrote:
> Doesn't matter, it's not what I asked. Trying to provide answers to a question that wasn't asked and was clearly stated I wasn't interested in those types of answers.

Every language has its own ways of solving various problems.
We are giving you solutions in D. If you don't want solutions in D, then what do you want?

On Tuesday, 12 July 2016 at 16:27:52 UTC, Adam Sansier wrote:
> On Tuesday, 12 July 2016 at 13:54:16 UTC, Lodovico Giaretta
>> Also note that yield semantics as available in various languages is much different from what you are proposing here.
>
> Not really. Yield is usually a break in flow, regardless just because it's applied to fibers doesn't mean it's *much* different. It's the same basic concept.

Across various programming languages, yield has two very different meanings and aims:
1) to achieve cooperative multitasking (as in D fibers); but you are not doing cooperative multitasking;
2) for generator functions (like in Python); but you don't have a function that generates multiple values.

Also note that in both cases the yielding does not depend on some syntax used at call site.

So, by any PL meaning of yield, yield is not what you need to solve your problem.

On Tuesday, 12 July 2016 at 16:42:52 UTC, Lodovico Giaretta wrote:
> On Tuesday, 12 July 2016 at 16:30:05 UTC, Adam Sansier wrote:
>> Doesn't matter, it's not what I asked. Trying to provide answers to a question that wasn't asked and was clearly stated I wasn't interested in those types of answers.
>
> Every language has its own ways of solving various problems.
> We are giving you solutions in D. If you don't want solutions in D, then what do you want?

It's pointless....