Is clarity worth O(n) in this context?

[drowsy kindle]

This module of my app will be used multiple times in my app so I want it to be as good as possible. It basically manages navigation by focusing elements.

For now I have it as you'll see in the script I've adjunted because I was looking for maximum clarity and readability at first glance. By defining the class Navigable and storing navigable items in a List<Navigable>, I thought it'd be much more readable, but that makes searches have a complexity of O(n). If I removed Navigable and used instead a Dictionary<Focusable, EventCallback<FocusOutEvent>>, searches complexity would go down to likely O(1), but I feel that won't be specially readable.

I know this is a quite silly question, but what do you think?

https://paste.ofcode.org/bSir2HHVVZ9td4dhR9f7Sd

[native niche]

!code

[hollow wigeon]

Posting code

📃 Large Code Blocks

Use links to services like:
https://paste.mod.gg/, https://hastebin.skyra.pw/, https://paste.ofcode.org/, https://paste.myst.rs/

📃 Inline Code

Surround code with three backquotes. Not quotation marks.
To format as C#, add cs to the first line:
```cs
// Your code here
```
Add a comment with a line number if there is an error message.

[native niche]

how many Navigables do you think you'll have in each NavigationHandler?

just a rough, conservative estimate

in the hundreds? in the thousands?

[drowsy kindle]

mb

[native niche]

nah you're good - no-one's gonna automatically know

[drowsy kindle]

probably no more than 100 objects, however due to object pooling Unregister method is likely to be called quite often

same with Register

[native niche]

ah, gotcha

are you referring to UpdateNavIndex with the readability thing?

[drowsy kindle]

not really, that won't change

the script isn't even finished

[native niche]

wdym it won't change lmao

dictionaries don't have indices

other than that method, i'm not seeing anything that would really change at all?

so if that's not your concern, i'm not seeing any potential readability issues

[drowsy kindle]

with readability i mean that Dictionary<Focusable, EventCallback<FocusOutEvent>> is less explicative than List<Navigable> being Navigable an inner class

[native niche]

(also, what are you object pooling on? you are still creating garbage with Navigable, perhaps that could be a struct given its usage?)

[native niche]

so what's wrong with Dictionary<Focusable, Navigable>?

i guess that's kinda unnecessary if you aren't using Navigable.Element anywhere else, but well.. i guess i don't really have that assumption

so, do you?

[drowsy kindle]

alr it will change

im sorry im so asleep today

[native niche]

you might want to get rest first

[drowsy kindle]

nope, its even private

[native niche]

i mean within this class, given that you said it's incomplete

[drowsy kindle]

the only thing i forgot is actually focusing elements, so I'd only need the Focusable

[native niche]

gotcha

so then yeah i suppose Dictionary<Focusable, EventCallback<FocusOutEvent>> would make the most sense

if you're concerned about the length/readability of the value type, i guess you could use using directives?

[drowsy kindle]

wdym?

[native niche]

and also var when retrieving

[native niche]

something like using FocusOutEventCallback = EventCallback<FocusOutEvent>;

[drowsy kindle]

Tried to use that but got compilation errors for some reason

I'll check it tomorrow

[native niche]

yeah it needs to be a qualified name iirc

[drowsy kindle]

Ty so much tho, I know Im been quite difficult but I'm half asleep

[drowsy kindle]

i think the thing that was worrying me the most was that the reader might interpret navigables as a mapping and not a list

the whole point of navigables was to store Focusables so I can Register, Focus and Unregister them

[native niche]

it being plural just means it's some kind of collection
an array, a list, a dictionary, a set, etc
what kind of collection it should be has to take into consideration its constraints and requirements - that's not something you can get just from the name

[drowsy kindle]

got an idea

maybe could define a delegate "FocusOutHandler" and then make the collection a Dictionary<Focusable, FocusOutHandler>

I think that leaves it pretty clear that I'm just storing navigables and even implies that my navigation works via focus

Oh yeah but then I couldn't use index

I'll just think later

I'm too tired lmao

[native niche]

https://learn.microsoft.com/en-us/dotnet/api/system.collections.generic.ordereddictionary-2?view=net-9.0
this seems to be a thing

[drowsy kindle]

Oh

[native niche]

btw, you could have NavigationDirection use 1/-1 as the backing values so you'd be able to cast to those values directly instead of the ternary

[drowsy kindle]

alr this seems to be perfect for my situation

[drowsy kindle]

I was open to the possibility of adding maybe NavigationDirection.Right and Left but yeah that doesnt sound bad

I don't think we'll ever make navigation bidirectional anyways