It's just a case of refactoring but some further thought is required even about the current filter improvement.
By creating a revised form of filter, for example, we have the option of making 'matches' take an RE and not a glob (shell wildcard expr). Yes REs are more complicated but much more generally useful. This would then lead to a 'matches operator' and a 'matches wildcard' operator. The code for this is in the filter command already - and the query expression impl would use the same code so it would be as fast as filter currently is. Warmest Regards, Mark. Sent from my iPhone > On 5 Aug 2018, at 13:37, Mark Wieder via use-livecode > <use-livecode@lists.runrev.com> wrote: > >> On 08/05/2018 11:20 AM, Mark Waddingham via use-livecode wrote: >> That isn't overloading put - that's introducing query expressions... >> Which would (at least as far as filter currently goes - I have another as >> yet unstated reason for suggesting a revised syntax beyond stopping my own >> mental torture!) eliminate the need for filter into. >> e.g >> the lines of X where Y >> Could be something which would work anywhere an expression does. > > As a long-term goal, I muchly like this. > >> However, small steps - the current filter code is tied to the filter command >> - so additions is easier to do there first as @Monte has demonstrated. > > No worries. Syntax aside, I tend to use the filter command quite a bit, as > the implementation in the engine is blazingly fast. > > -- > Mark Wieder > ahsoftw...@gmail.com > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
