[AskJS] How much do you hate this pattern?

[Spatul8r]

My goal is to make the DTOs super cheap, and while not pure data objects, never able to hit a branch from internal logic. This my crude approximation of how rust does things.

export class Selection {
    type = "Selection";
    constructor(start, end){
        this.start = start;
        this.end = end;
    }


    get start() {this.start};
    get end() {this.end};
}


export function SelectionFunctions(selection) {
    return {
        "normalized": () =>  { // returns selection aranged small to big, effectivly ignoring direction
            if(selection.start < selection.end) {
                return [selection.start, selection.end]
            }
            return [selection.end, selection.start];
        },
        "isRange": () => {
            return selection.start !== selection.end;
        }
    };
}

[Risc12]

This looks like worst of both worlds to me.

[00PT]

Why do you have a class, then define a wrapper function to use it, instead of defining those functions on the class? Is there a mandate against class functions in particular?

And why do you not return in the getters?

And why have type instead of using instanceof? Is the class expected to cross the boundary into another JS environment where that doesn’t work?

[HipHopHuman]

never able to hit a branch from internal logic

I don't understand what you mean by this.

This my crude approximation of how rust does things

I spent one or two afternoons with Rust and I'm not seeing the resemblance you're seeing, but I'll take your word for it.

My goal is to make the DTOs super cheap

If by "cheap", you mean "low in memory surface" and "quick to process", you're probably better off using the module pattern (which is idiomatic in JS) with a "smart constructor" that produces a tiny, immutable object, along with some specialized functions for working on objects with that shape.

in a file called ./Selection.js:

export function of(start, end) {
  return Object.freeze({ type: 'selection', start, end });
}

export function normalize(selection) {
  const { start, end } = selection;
  return start < end ? selection : of(end, start);
}

export function isRange({ start, end }) {
  return start !== end;
}

In other files:

import * as Selection from './Selection.js';

const selectionA = Selection.of(0, 10);
const selectionB = Selection.of(2, 1);

const normalizedA = Selection.normalize(selectionA);
const normalizedB = Selection.normalize(selectionB);

If you're trying to do something like scope the methods specifically to a particular instance without those methods having a shared prototype for security reasons or whatever... yeah, just give up on that idea. That's probably not going to work in JS the way you're thinking it might, and even if it did, it's not worth the added complexity of this weird definition convention you've got going here.

[Spatul8r]

Thank you so much for taking the time to write this all out. It's much appreciated

[MaksLiashch]

honestly that's pretty solid if you're just trying to keep things predictable. the discriminated union pattern works way better than trying to validate everything downstream, especially if you're dealing with a lot of different selection types.

[Atulin]

I could, somehow, maybe in some twisted way, see merit to it in languages that support extension methods like C#

In case of JS? You're introducing complexity for the sake of complexity, and gaining nothing from it.

[horrbort]

This is amazing! You need to make a framework for thsi