You may be aware the length[] operator has, or needs no parameter, so it would be backward compatible if we permitted a parameter of length “number”".
eg; length[8] which would only return the input value if the input is of length 8
This we would reduce [[input]length[]match[8]] or the even less friendly compare operator, with [[input]length[8]] In this example nothing is returned!
It should be trivial to code.
The first thing I thought was. What’s wrong with length[]match[8]?
And then: How can we make show more or less than 8. We do have the compare-operator for that. So we should use it.
It just seems to be the length operator could be used to count or match since the operator is not in use. If we can do something with one operator rather than two seems better to me.
length[5],[8] and it would be nice when you compare it to the equivalent using the compare operators needed.I’m not a big fan of an operator having more than one purpose.
LENGTH returns the length of a value as long as LENGTH does not have a parameter.
LENGTH filters out a value when the value’s length is not equal to the parameter when a parameter is specified.
That kind of overloading is very confusing.
I very strongly agree. Keep it simple! And by this, I mean “simple” by the definition Rich Hickey presents in Simple Made Easy.
IMO “less friendly” is in the eye of the beholder. The compare-operator is very verbose, which makes it easy to understand. You are right, it also makes it a bit “bulky” to type.
On the other hand, since TW v5.3.0 (July 2023) we can define our own filter functions. So if we know, that we get string inputs, we could define a function like eg: f.lteg[5]
\function f.lteq(nr) [length[]compare:number:lteq<nr>]
{{{ [[ab cd]f.lteq[5]] }}}
All of this is perfectly fine, if it is done in a consistent way, within the realm of the specific use-case.
For this specific usecase we turn the number of characters of an input into a number and we compare it to a dynamic value.
Most of the time the TW core prefers verbosity and focuses on 1 functionality, which can be “splitted” up into smaller “simple” pieces.
So “simple” building blocks can be used to create more powerful and more abstract functions.
As I wrote. These custom functions most of the time are very specific to a certain usecase.
For the core we try to be as generic as possible and to keep it “simple”. There should be only one way to solve a specific problem.
I think we should explore the possibilities we have.
Creating custom filter functions is a relatively “new art” in TiddlyWiki and we only start to understand the possibilities they give us.
The big advantage is, that it can be done by every user out of the box.
If we would change the behaviour of the length[] operator to length[x], we would “mimic” length[]match[x]
If we implement length[min],[max] from the second comment we would mimic a limited version of the the compare-operators
Most importantly, we would need to modify the core and we do not even know, if that covers all the possible use-cases.
just my thoughts
-mario
Ok we may all think different ways but to me this is trivial and not at all confusing when I read length[] or length[6] I Personaly see no other way to read this than the behaviour I propose.
In fact the idea of testing the length of someting with the addition of the match parameter is the more complex.
Everyone who has replied is familular already with match and compare. I think this is a bias that ignores how a new user may read this. In fact they may search for length filter and be disappointed it does not filter titles of a given length.
To achive this the only documentation change is when the parameter is given.
We have other operators that change between selection and constructors this way.
The advantage of the length[N] is if it tests true it passes the title through it is a selector, which further reduces complexity.
And what do you think when you read length<my-var>? Might you find it surprising to find the change in behavior on that rare instance when my-var happens not to contain an integer but a blank string? I would definitely prefer to use a custom function with a clear name for the proposed new behavior. If it seems useful enough, it could make it to the core.
Almost a decade ago, I wrote a post on the complexity of function signatures, and came down strongly on the side of simpler-is-better: https://fr.umio.us/ranging-near-and-far/. Nothing has happened since to change my mind.
By the way, the reason I seek this is to improve the opportunity to test a field value meets a particular format. I have developed a method to determin alpha, numeric and other character formats and compare this to a pattern. For example checking if a date stamp is, is it numerical and 17 long and I then want to format as a date.
Well lets agree to disagree, I only propose a change that follows current approaches and makes the operator more functional. If I have my way your erroroniouse use where with a blank <my-var> can only be a problem with future code and we can document the default eg 0.
Post script
If there was a reason not too use length, I dont think there is, then we can use stringlength etc…
My only objection was to using length like this in two very different ways, depending on the parameters passed. I would be absolutely fine with another name, and it does strike me as a useful idea. Perhaps haslength?
Tones, really, take the coders’ advice here. Creating a utility (function) that does more than one thing (worse, sometimes) is a bad idea™. It breaks so many rules of good engineering it’s too tedious to list them all. See function do one thing well at DuckDuckGo
Consider…
function takeTheTrashOut()
performActionsToTakeTheTrashOut()
if(sky==="blue") {
bringInTheMail()
}
}
function bringInTheMail() {
performActionsToBringInTheMail()
}
takeTheTrashOut()
bringInTheMail()
Promote @Scott_Sauyet’s haslength[]
Yes, as I said;
Although not withstanding this if we take length as being used to “obtain or determine length” of strings then when it has a parameter it, passes through the strings of that length, and if not it gives us the length, is not really different to other filters that can be used as both selector and constructors - see the C column here especially when marked C? such as ALL and SUBFILTER.
This is of course common practice if that thing is related, I would argue what I propose “is related”. However this is not an argument I need to win, as it may suffice to just have the functionality.
When it comes to sound engineering, it’s not a case of winning the argument, it’s a case of honoring the weight(ier) views, even when they’re opposing your own.
A common practice does not a good idea guarantee.
In my experience, aside from creating a syntactically overloaded mess re the language, it makes for messy implementation. Bad for supporting/maintaining the behind-the-scenes code that makes whatever product work.
In my previous career, users would always ask me if such-and-such a feature could be added to the system. I’d always say “I can make the system do anything short of pumping out toast. But it is going to cost something silly.”
Or: so expensive that the cost of doing it cannot be measured. And if the cost cannot be measured, then the thing should not be done.
That in effect what I was saying. But I also use the term ‘argument’ as a philosopher or scientist does, not like the couple next door.
Charlie I don’t think we disagree on common practice.
When I mention “common practice” it is from the perspective of a committed sceptic, yet if something is existing common practice and you do not account for it, all your solutions my be bespoke and not part of a systematic whole.
Reading length[] and length[5] even length[0] are all meaningful to my eyes. In english the first is the length is unknown so return it, the subsequent we ask for a specific length, so return cases of that length.
I agree with the principles every one has presented. I do not agree with there application in this case.
At the same time I suggested 'stringlength[]` to "avoid the contraversy. But that did not work :
I’m fine with new operators for new features, but multi-purpose operators are a major turn off. Not just from the end-user perspective, but more importantly:
Multi-purpose features make for messy code to support/maintain such features, and messy core code makes for greater risk of instability.
A new feature with isolated code to support that feature is better for the robustness of any system. A bunch of if-then conditions in the implementation of length (to handle various functional purposes) makes the code for length more brittle.
Now if you’re just making an argument for a new operator, fine by me (and please ignore my ranting here). I support the addition of new operators.
But if you’re still arguing the case for multi-purpose length, then I’ll continue raising a stink about it because that’s how badly I do not want length doing that.
If you’re suggesting a new single-purpose operator, you will get little pushback from the people who’ve spoken up here. But we are objecting to any multipurpose operator, probably all from long experience with the problems those create.
Ditto that. Very much ditto that.