Opens the option to expand objects - by removing "sealed"

[danielmayost]

Is your feature request related to a problem? Please describe.
I would be happy if there was more flexibility to expand existing objects in the project, like ProgressTask, for that matter, I owe a version of it with a few more Properties.

This was a problem for me with a few other objects like Table etc.

Describe the solution you'd like
Why must all objects be locked for expansion, with sealed? It will be more flexible to leave users more options.

[patriksvensson]

@danielmayost That kind of flexibility leads to a lot of bugs, therefore everything is sealed by default. We prefer to extend things using composition if we can in the first place and avoid inheritance.

[danielmayost]

ok, got it.

[LazyTarget]

Hi, I discovered this wonderful library a few weeks ago! 😄
Now for my application I have a few things that I wanna extend for the TextPrompt and the MultiSelectionPrompt

@patriksvensson
While I understand the reasoning for using sealed, I also think that it hinders extensibility
For me to a add a simple feature to the TextPrompt, I would need:

1. to either make a hard copy of the current code (and other refrenced types that are internal) and then modifying to my scenario
2. or I would need to implement the whole prompt logic from scratch. Which probably would lead to worse quality, missing features and and more time needed. Also missing out on any need features in future package releases

I think removing sealed and possibly adding virtual at strategic places, would open up more and leave that decision to the person that is extending?

This is just my thoughts when looking at it now. Maybe someone could explain if I am seeing it the wrong way?

[patriksvensson]

@LazyTarget I understand what you mean, but unsealing things just for the sake of making things more extensible also increases the maintenance burden. I would rather prefer that we unseal things as needed, or find a better way of extending things. TextPrompt for example was never meant for extensibility outside of the Spectre.Console projects, so if we know what "hurts" with it, maybe we can make it easier to reuse in a more strategic way.

[LazyTarget]

Ok I see 👍

Well I had two features:

1. Able to cancel a prompt
2. A flag that uses choices more like suggestions. So that you can input a value that is not listed in the choices

I could take them as separate issues as this might be out of scope

[LazyTarget]

But for the 2nd feature it might be more relevant to implement it separately since that would require a converter in the reverse order (Func<string, T>)

[BobSilent]

I have a similiar question:

I also want to extend the progress view: I have a progress task which analyzes items, and for the example lets say it categorizes each item into e.g. Apple or Banana.
I want to show 3 Columns:

1. TaskDescriptionColumn
2. ProgressBarColumn
3. a Custom Column showing how many Apples and Bananas have been identified

I can create a Custom ProgressColumn but unfortunately in public abstract IRenderable Render(RenderContext context, ProgressTask task, TimeSpan deltaTime) it requires a ProgressTask task, but this is public sealed class ProgressTask : IProgress<double>.

So I would also like to ask if

• either the sealed from class ProgressTask can be removed...
• or if an interface IProgressTask can be extracted, which can be used in the public abstract IRenderable Render(RenderContext context, IProgressTask task, TimeSpan deltaTime).
  This would also allow me to extend via composition and keeps the original ProgressTask sealed.