"important" flag for wrapFunction?

e016 commented

2026-04-28 11:52:26 -05:00

(Migrated from github.com)

My addon "better flat design" modifies the rendering of input slots.

If I were to make a "Split! block design" addon, the two addons would try to overrite each other. Obviously we'd want the Split! input slots, not the snap-like ones of better flat design.

I've thought of making an important/unimportant flag in wrapFunction, maybe like this?

wrapFunction(
    InputSlotMorph.prototype, 
    "render", 
    () => {}, 
    true, 
    true // "unimportant"/"replaceable" flag
)

My addon "better flat design" modifies the rendering of input slots. If I were to make a "Split! block design" addon, the two addons would try to overrite each other. Obviously we'd want the Split! input slots, not the snap-like ones of better flat design. I've thought of making an important/unimportant flag in wrapFunction, maybe like this? ```js wrapFunction( InputSlotMorph.prototype, "render", () => {}, true, true // "unimportant"/"replaceable" flag ) ```

PPPDUD commented

2026-04-28 11:54:09 -05:00

(Migrated from github.com)

My addon "better flat design" modifies the rendering of input slots.

If I were to make a "Split! block design" addon, the two addons would try to overrite each other. Obviously we'd want the Split! input slots, not the snap-like ones of better flat design.

I've thought of making an important/unimportant flag in wrapFunction, maybe like this?

wrapFunction(
InputSlotMorph.prototype,
"render",
() => {},
true,
true // "unimportant"/"replaceable" flag
)

Perhaps a numerical priority system might be better? For example, the block design addon would have a priority of 2, and the better flat design addon would have a priority of 1. Sparkle's stuff would have a priority of 0 to permit patching from its addons.

> My addon "better flat design" modifies the rendering of input slots. > > If I were to make a "Split! block design" addon, the two addons would try to overrite each other. Obviously we'd want the Split! input slots, not the snap-like ones of better flat design. > > I've thought of making an important/unimportant flag in wrapFunction, maybe like this? > > wrapFunction( > InputSlotMorph.prototype, > "render", > () => {}, > true, > true // "unimportant"/"replaceable" flag > ) Perhaps a numerical priority system might be better? For example, the block design addon would have a priority of 2, and the better flat design addon would have a priority of 1. Sparkle's stuff would have a priority of 0 to permit patching from its addons.

e016 commented

2026-04-28 11:56:03 -05:00

(Migrated from github.com)

Perhaps a numerical priority system might be better? For example, the block design addon would have a priority of 2, and the better flat design addon would have a priority of 1. Sparkle's stuff would have a priority of 0 to permit patching from its addons.

Yeah, I thought of that, although I was worried that there would be inconsistency between number priorities (e.g: split and flat design accidentally use priority 2)

> Perhaps a numerical priority system might be better? For example, the block design addon would have a priority of 2, and the better flat design addon would have a priority of 1. Sparkle's stuff would have a priority of 0 to permit patching from its addons. Yeah, I thought of that, although I was worried that there would be inconsistency between number priorities (e.g: split and flat design accidentally use priority 2)

PPPDUD commented

2026-04-28 12:02:29 -05:00

(Migrated from github.com)

Perhaps a numerical priority system might be better? For example, the block design addon would have a priority of 2, and the better flat design addon would have a priority of 1. Sparkle's stuff would have a priority of 0 to permit patching from its addons.

Yeah, I thought of that, although I was worried that there would be inconsistency between number priorities (e.g: split and flat design accidentally use priority 2)

Perhaps we could have a function called api.conflictsWithAddon() or something like that, and it throws an error if an addon with a given ID already exists, so that such conflicts are less likely?

We could also make a database of wrapped functions, the associated addons, and the priority levels, so that developers know what precautions to take beforehand.

> > Perhaps a numerical priority system might be better? For example, the block design addon would have a priority of 2, and the better flat design addon would have a priority of 1. Sparkle's stuff would have a priority of 0 to permit patching from its addons. > > Yeah, I thought of that, although I was worried that there would be inconsistency between number priorities (e.g: split and flat design accidentally use priority 2) Perhaps we could have a function called `api.conflictsWithAddon()` or something like that, and it throws an error if an addon with a given ID already exists, so that such conflicts are less likely? We could also make a database of wrapped functions, the associated addons, and the priority levels, so that developers know what precautions to take beforehand.

e016 commented

2026-04-28 12:11:58 -05:00

(Migrated from github.com)

We could also make a database of wrapped functions, the associated addons, and the priority levels, so that developers know what precautions to take beforehand.

Isn't that a bit too much?

Perhaps we could have a function called api.conflictsWithAddon() or something like that, and it throws an error if an addon with a given ID already exists, so that such conflicts are less likely?

I think that might work, for debugging

> We could also make a database of wrapped functions, the associated addons, and the priority levels, so that developers know what precautions to take beforehand. Isn't that a bit too much? > Perhaps we could have a function called `api.conflictsWithAddon()` or something like that, and it throws an error if an addon with a given ID already exists, so that such conflicts are less likely? I think that might work, for debugging

PPPDUD commented

2026-04-28 12:14:02 -05:00

(Migrated from github.com)

We could also make a database of wrapped functions, the associated addons, and the priority levels, so that developers know what precautions to take beforehand.

Isn't that a bit too much?

True, but do you have a better solution to this problem? Your important flag is essentially the same thing but with higher chances of a conflict.

> > We could also make a database of wrapped functions, the associated addons, and the priority levels, so that developers know what precautions to take beforehand. > > Isn't that a bit too much? > True, but do you have a better solution to this problem? Your important flag is essentially the same thing but with higher chances of a conflict.

e016 commented

2026-04-28 12:19:55 -05:00

(Migrated from github.com)

We could also make a database of wrapped functions, the associated addons, and the priority levels, so that developers know what precautions to take beforehand.

Isn't that a bit too much?

True, but do you have a better solution to this problem? Your important flag is essentially the same thing but with higher chances of a conflict.

Yeah, I was always worried about that. I don't know how else to do this :-(

> > > We could also make a database of wrapped functions, the associated addons, and the priority levels, so that developers know what precautions to take beforehand. > > > > > > Isn't that a bit too much? > > True, but do you have a better solution to this problem? Your important flag is essentially the same thing but with higher chances of a conflict. Yeah, I was always worried about that. I don't know how else to do this :-(

PPPDUD commented

2026-04-28 12:24:13 -05:00

(Migrated from github.com)

We could also make a database of wrapped functions, the associated addons, and the priority levels, so that developers know what precautions to take beforehand.

Isn't that a bit too much?

True, but do you have a better solution to this problem? Your important flag is essentially the same thing but with higher chances of a conflict.

Yeah, I was always worried about that. I don't know how else to do this :-(

Let's try out a numerical priority system with no database. At our scale, it's unlikely to cause any major issues, and if it does, we'll figure out something better.

> > > > We could also make a database of wrapped functions, the associated addons, and the priority levels, so that developers know what precautions to take beforehand. > > > > > > > > > Isn't that a bit too much? > > > > > > True, but do you have a better solution to this problem? Your important flag is essentially the same thing but with higher chances of a conflict. > > Yeah, I was always worried about that. I don't know how else to do this :-( Let's try out a numerical priority system with no database. At our scale, it's unlikely to cause any major issues, and if it does, we'll figure out something better.

Bubgamer07 commented

2026-05-06 17:30:24 -05:00

(Migrated from github.com)

What if the user could choose? By default newer mods could have priority but the user could change the priority by doing something like dragging the mods in a list?

PPPDUD commented

2026-05-06 17:33:24 -05:00

(Migrated from github.com)

What if the user could choose? By default newer mods could have priority but the user could change the priority by doing something like dragging the mods in a list?

I like the idea of dragging the addons, but could we make it to where the newer addons are lower priority, and preloaded addons get the highest priorities by default, above user-installed addons?

> What if the user could choose? By default newer mods could have priority but the user could change the priority by doing something like dragging the mods in a list? I like the idea of dragging the addons, but could we make it to where the newer addons are lower priority, and preloaded addons get the highest priorities by default, above user-installed addons?

Bubgamer07 commented

2026-05-06 17:36:23 -05:00

(Migrated from github.com)

What if the user could choose? By default newer mods could have priority but the user could change the priority by doing something like dragging the mods in a list?

I like the idea of dragging the addons, but could we make it to where the newer addons are lower priority, and preloaded addons get the highest priorities by default, above user-installed addons?

Sounds good!

> > What if the user could choose? By default newer mods could have priority but the user could change the priority by doing something like dragging the mods in a list? > > I like the idea of dragging the addons, but could we make it to where the newer addons are lower priority, and preloaded addons get the highest priorities by default, above user-installed addons? Sounds good!

👍 1

e016 commented

2026-05-21 22:29:21 -05:00

(Migrated from github.com)

Closed with #35

Rows
Columns

"important" flag for wrapFunction? #33