Feature: Linking via the member/method name

[mikej0]

Hello,

Just a thought that in classes with long chains where you want to slot a new call in the middle, perhaps it could be possible to link by the name of the member or method instead of a number? Then we don't need to increase all following calls by 1 each time.

So for example:

[FluentMember] // First
public string Name { get; private set; }

[FluentMember("Name")] // Follows after member "Name"
public int Age { get; private set; }

[FluentMethod("Name")]
[FluentContinueWith("Age")]
public void Address(string address) { }

Or for type safety, is it possible to automate creating an enum with the names instead of magic strings?

[FluentMember] // First
public string Name { get; private set; }

[FluentMember({Name}Members.Name)] // Follows after member "Name"
public int Age { get; private set; }

[FluentMethod({Name}Members.Name)]
[FluentContinueWith({Name}Members.Age)]
public void Address(string address) { }

Or something similar...

Thanks

Mike

[m31coding]

Hi Mike,

Thank you for your suggestion! I see the benefit of introducing a new step between two existing steps without modifying the latter. Your proposed solution could work well if there are no forks involved. However, in cases where there are multiple members or methods at the same step, using one of the member names for the step might not be ideal and could confuse users, especially new ones.

As an alternative, I suggest changing the step type from int to double. This way, steps can be numbered like 1, 2, 2.1, 2.2, 2.3, 3, etc. This would also allow more flexibility in inheritance scenarios, where new steps could be inserted in derived classes without affecting the base class.

Do you think this approach would work for your use case?

Best regards,
Kevin

[mikej0]

Hi Kevin,

Ah, yes, I hadn't thought of those issues. :-) Another issue is that to insert a step, you'd also have to override the attribute on following steps to point at the new one rather than the old one. Not ideal.

I think doubles could help a little bit, but could there be some limitations there as well?

So supposing I start off with
Step 1
Step 2

And I want to add a couple of steps in the middle, those could be (going with middle numbers so there's space for more expansion above and below)
Step 1
Step 1.5
Step 1.6
Step 2

But to be awkward, if I then wanted to introduce another between .5 and .6...?
Step 1
Step 1.5
Step 1.55?
Step 1.6
Step 2

Just like this, I don't think we'd be able to say that this is either step 55 or step 5.5.

Could a semver style string could allow for unlimited modifications? "1.5.5.x.x"? It might lose it's type safety though, unless it's easy to have the ide pop up an error on something it doesn't recognise. Or maybe an array of ints? [1 ,5 ,5]?

Cheers,

Mike

[mikej0]

I may have been over-thinking it. .55 is half way between .5 and .6. If I think of it as a number, rather than a step pattern, then I think it does work. It's just every step between two other numbers means extending the decimal places by 1 each time. I think doubles could work...

Does an array of ints make it clearer to see the pattern of steps without getting lost in a long number? Maybe?

Mike

[m31coding]

Semver or an array approach is interesting, but would require additional Fluent Attribute constructors. I lean towards keeping the API slim and simple. The double approach is effectively equivalent to Semver or an array, assuming the values are constrained between 0 and 1. Note that since there are infinitely many numbers between any two real numbers, this approach is only limited by double precision.

In your example, I might use 1, 2, then 1, 1.1, 1.2, 2, and then 1, 1.1, 1.11, 1.2, 2, though that's personal preference.

If we don't find strong arguments against the double approach, I'll aim to implement it within the next two weeks.

Cheers!,
Kevin

[mikej0]

Good morning.

I can't think of any strong arguments against doubles, and haven't thought of anything better or as straight forward. The only arguments I can think of against it are that it changes the approach. With whole numbers it's easy to see the steps, as it's literally step 1, step 2.

Step 1.23456 doesn't look or feel very elegant to me, and I think it also changes the definition of what is a step, which I wonder could cause confusion and might take a bit of explaining?

If anyone else asks for this, I'd probably say go for it, otherwise I can happily live with the current method and we can wait until another idea comes up or others suggest this would be useful for them as well. 🙂

Basically, I'm thinking let's not muddy the waters for my benefit, unless you come to the conclusion it's the best route forward overall.

Thanks!

Mike

[m31coding]

Hi Mike,

Thank you very much for your thoughts. I agree that the solution I proposed may not be the most elegant approach; I will not implement it for now. Let's see if more people demand a solution to this issue. If this is the case, I would be open to adopting the solution with the step expression string, e.g. "1.5.5", and adding new constructors for the Fluent API attributes.

In the meantime, you might want to try using larger integer steps, like this:

Step 0, Step 128
Step 0, Step 64, Step 128
Step 0, Step 64, Step 96, Step 128
Step 0, Step 64, Step 80, Step 96, Step 128
a.s.o

Please let me know if this worked for you.

Best regards,
Kevin