https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30915
Marcel de Rooy <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |BLOCKED --- Comment #7 from Marcel de Rooy <[email protected]> --- (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. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
