search

varnishcache / varnish-cache

Varnish Cache source code repository
https://www.varnish-cache.org
Other
3.63k stars 374 forks source link

[Discuss] VIP28 designated object methods aka $Cast #3141

Closed nigoroll closed 4 years ago

nigoroll commented 4 years ago

@Dridi and @nigoroll kindly ask for feedback on

https://github.com/varnishcache/varnish-cache/wiki/VIP28:-designated-vmod-object-methods

nigoroll commented 4 years ago

bugwash:

nigoroll commented 4 years ago

todo from IRC discussions with @bsdphk :

FTR some guidance:

(16:14:03) phk: the focus would become struct expr from vcc_expr.c, that would have a method-function array for its current type. (16:14:27) phk: those method functions would edit the C-expression string the way the vcc_expr.c code does now (16:15:05) phk: ie: INT.add(expr1, expr2) would return an expr being essentially textprocessing "%s + %s", expr1, expr2 (16:15:49) slink: yeah got it (16:15:56) phk: (Unless we decide CPUs are fast enough to suffer a functional at runtime for integer addition.) (16:16:41) phk: s/functional/function-call/ (16:20:24) slink: I took your example as for an intermediate step. sure, if INT was a vmod class, that would be a function call (16:20:57) phk: well, my point is I want the types .add() method to decide if the generated C code does a call or not (16:21:28) phk: Ie: move that kind of policy decisions into per-type object-method vectors (16:21:30) slink: sure (16:22:04) slink: that is in line with my mental model

bsdphk commented 4 years ago

I will register my "No" on this proposal here.

That is a firm no, not to the goal, but to the approach to reaching it.

I will lay out how to go about this in the VIP.

dridi commented 4 years ago

I think that after the bugwash discussion we can agree that VIP 28 isn't as ambitious as what we discussed. I'm fine with closing this as well.

nigoroll commented 4 years ago

@Dridi why not reuse VIP28 to collect @bsdphk s input?

dridi commented 4 years ago

Because I think the direction that was described is more like a generalization of VIP12 [1], so I'd edit this one instead to be more comprehensive and not just cover VMOD $Objects.

[1] that ultimately would also result in something very different than what's currently in the wiki

nigoroll commented 4 years ago

/me curious about what is going to come back