https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30915 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |BLOCKED --- Comment #7 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to Tomás Cohen Arazi (tcohen) from comment #4)
I agree with the change and things look ok.
My only concern is:
* Should we deprecate it first? (e.g. people might be using it in notices) * In the event we remove it (via deprecation window or not), shouldn't we provide an alternative approach at least in the documentation?
I noticed the feature doesn't seem to have tests implemented.
Thx for signing off here. Legitimate questions! I assume (..) that we will have not much people using this in notices based on the fact that we only used the construct in our codebase just a few times too. But I think that we definitely should warn people who do use it in notices. Since this will probably be a small number and manually replacing them should not be so hard, I tend to think that a warning dbrev should be sufficient. Will add that now. The refactoring pattern is Replace Context.Scalar( $x, $y ) by just $x.$y if you know that method y (like search and friends) will be a scalar (resultset). This was the case in the templates. If method y returns a list and was "Scalared" then you need to add a count to get at the same result. So in that case replace Context.Scalar( $x, $y ) by $x.$y.count. Note that this was probably not used like that, since using Scalar for that is unnecessary complexity for $x.$y.count already. -- You are receiving this mail because: You are watching all bug changes.