I have custom rules (CustomRules.js) from where I can do anything, but... when I use the Autoreponder I can't add a double codition like this but not this in same clause.
I really think that this cannot be done by design of that feature, but wanna be sure before leaving it.
Note: I know I can add two conditions, one per field/rule, what I want is to use any kind of operator like URLWithBody that has 2 strings on it. I suspect that is a special function accepting 2 arguments.
Im not english, not that few words may be misstyped.
Related
Curious to know if Swift permits the use of search operators like the wildcard "*" or the exclusive "-" or Boolean search operators like AND, OR and NOT. By search operators I mean symbols an app user would input into a text box to narrow a search. I think NSPredicate's LIKE allows the use of "*" and "?". But I have not come across online examples of search operators used in connection with swift's often cited filtering code:
object.filter{$0.objectProperty.contains(searchText)}
If someone could point me in the right direction of some literature I would be grateful. I would be interested to learn how to make it possible for an app user to use search operators referenced above and/or use something like the following to narrow a search: dog w/20 food
The latter search term would find all instances of "dog" within 20 characters of "food."
The filter on Swift's array Is simply a method that returns it's own type, using a passed function that returns a Bool. So the short answer is, there's nothing related to the "filter" function that allows you to do anything like what you're talking about.
One common way to filter/find things is to use Regular Expressions which are supported by Swift. (You can search here for more specific info).
If you have everything in a database and expect your users to know how to write Predicates, I suppose you could use CoreData and search with a string from the user, but that seem pretty unlikely.
Outside of those options you will probably need to search for a third party library or build some sort of parser yourself.
I'm trying to implement a ruleset-type table for a bunch of questions in a form. I've got down the table for that ruleset, but originally I was going to just have them all in "AND"s. But I need to include ORs as well, and that means including brackets in to the equation. I'm not too sure how to implement it. I'm trying to figure out what the table needs or if it needs another table.
So this is an example of what I'm thinking.
{FieldRule: FieldRuleId, RuleId, FieldId}
When I get the other information, it'll evaluate to to True/False. How can I do it so I can do combinations of (Rule1 ^ Rule2) V Rule3?
Thanks!
Bump!
Last bump!
I implemented a Reverse Polish Notation system whereby I added the truth values to a stack as well as the OR and AND symbols. This seems to work very well! If anybody would like any further help on something like this, feel free to comment.
I currently have the following grammar below:
COMPONENT = HEADER BODY
BODY = ELEMENT+
ELEMENT = EXPRESSION | DECLARATION | DESCRIPTION | NAME
I would like to assert that the body must have one of each of the ELEMENT in any order. Currently I am checking this after parsing, I am however curious if it's possible to express this in the grammar using Parser Combinators particularly guards
I tried doing further research regarding this, but nothing seems to come up.
Yes, it is possible. You simply write down all the valid permutations. This gets out of hand, fast.
It isn't worth the trouble to express in the grammar, because in essence you are trying to establish a constraint across the syntax, and grammars are really best at expressing context-free constraints.
Better to parse with grammar rules simply allowing all of the possibles clauses as options, and build your semantic pass (you will have one anyway) to check the additional constraints.
When writing a grammar, you should move as many constraints as possible to the semantic pass instead of the syntactic pass. This greatly improves the ability of the parser to recover from errors during parsing, and allows you to fully control the manner and wording used when reporting the error to users. For the case of permutations, the increased flexibility in the parser will likely reduce the size of the parsing tables as well.
This is a general design question not relating to any language. I'm a bit torn between going for minimum code or optimum organization.
I'll use my current project as an example. I have a bunch of tabs on a form that perform different functions. Lets say Tab 1 reads in a file with a specific layout, tab 2 exports a file to a specific location, etc. The problem I'm running into now is that I need these tabs to do something slightly different based on the contents of a variable. If it contains a 1 I may need to use Layout A and perform some extra concatenation, if it contains a 2 I may need to use Layout B and do no concatenation but add two integer fields, etc. There could be 10+ codes that I will be looking at.
Is it more preferable to create an individual path for each code early on, or attempt to create a single path that branches out only when absolutely required.
Creating an individual path for each code would allow my code to be extremely easy to follow at a glance, which in turn will help me out later on down the road when debugging or making changes. The downside to this is that I will increase the amount of code written by calling some of the same functions in multiple places (for example, steps 3, 5, and 9 for every single code may be exactly the same.
Creating a single path that would branch out only when required will be a bit messier and more difficult to follow at a glance, but I would create less code by placing conditionals only at steps that are unique.
I realize that this may be a case-by-case decision, but in general, if you were handed a previously built program to work on, which would you prefer?
Edit: I've drawn some simple images to help express it. Codes 1/2/3 are the variables and the lines under them represent the paths they would take. All of these steps need to be performed in a linear chronological fashion, so there would be a function to essentially just call other functions in the proper order.
Different Paths
Single Path
Creating a single path that would
branch out only when required will be
a bit messier and more difficult to
follow at a glance, but I would create
less code by placing conditionals only
at steps that are unique.
Im not buying this statement. There is a level of finesse when deciding when to write new functions. Functions should be as simple and reusable as possible (but no simpler). The correct answer is almost never 'one big file that does a lot of branching'.
Less LOC (lines of code) should not be the goal. Readability and maintainability should be the goal. When you create functions, the names should be self documenting. If you have a large block of code, it is good to do something like
function doSomethingComplicated() {
stepOne();
stepTwo();
// and so on
}
where the function names are self documenting. Not only will the code be more readable, you will make it easier to unit test each segment of the code in isolation.
For the case where you will have a lot of methods that call the same exact methods, you can use good OO design and design patterns to minimize the number of functions that do the same thing. This is in reference to your statement "The downside to this is that I will increase the amount of code written by calling some of the same functions in multiple places (for example, steps 3, 5, and 9 for every single code may be exactly the same."
The biggest danger in starting with one big block of code is that it will never actually get refactored into smaller units. Just start down the right path to begin with....
EDIT --
for your picture, I would create a base-class with all of the common methods that are used. The base class would be abstract, with an abstract method. Subclasses would implement the abstract method and use the common functions they need. Of course, replace 'abstract' with whatever your language of choice provides.
You should always err on the side of generalization, with the only exception being early prototyping (where throughput of generating working stuff is majorly impacted by designing correct abstractions/generalizations). having said that, you should NEVER leave that mess of non-generalized cloned branches past the early prototype stage, as it leads to messy hard to maintain code (if you are doing almost the same thing 3 different times, and need to change that thing, you're almost sure to forget to change 1 out of 3).
Again it's hard to specifically answer such an open ended question, but I believe you don't have to sacrifice one for the other.
OOP techniques solves this issue by allowing you to encapsulate the reusable portions of your code and generate child classes to handle object specific behaviors.
Personally I think you might (if possible by your API) create inherited forms, create them on fly on master form (with tabs), pass agruments and embed in tab container.
When to inherit form and when to decide to use arguments (code) to show/hide/add/remove functionality is up to you, yet master form should contain only decisions and argument passing and embeddable forms just plain functionality - this way you can separate organisation from implementation.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I need a good variable name for a boolean value that returns false when an object is the last in a list.
The only decent name I can come up with is 'inFront', but I don't think that is descriptive enough.
Another choose would be 'isNotLast'. This is not good practice though (Code Complete, page 269, Use positive boolean variable names).
I am aware that I could change the variable definition. So true is returned when an object is the last and call the variable 'isLast', however, it would make this task easier if I had the first explanation.
isBeforeTheLastItem
isInFrontOfTheLastItem
isTowardsTheFrontOfTheList
Maybe too wordy but they may help give you ideas.
My vote would be to name it IsLast and change the functionality. If that isn't really an option, I'd leave the name as IsNotLast.
I agree with Code Complete (Use positive boolean variable names), I also believe that rules are made to be broken. The key is to break them only when you absoluately have to. In this case, none of the alternative names are as clear as the name that "breaks" the rule. So this is one of those times where breaking the rule can be okay.
hasFollowingItems? or hasFollowingXXXXs where XXXX is whatever the item in your list is?
Personally more than anything I would change the logic, or look at the business rules to see if they dictate any potential naming.
Since, the actual condition that toggles the boolean is actually the act of being "last". I would say that switching the logic, and naming it "IsLastItem" or similar would be a more preferred method.
isPenultimateOrPrior
isBeforeEnd
Haskell uses init to refer to all but the last element of a list (the inverse of tail, basically); would isInInit work, or is that too opaque?
How about:
hasSiblings
or isFollowedBySiblings (or isFolloedByItems, or isFollowedByOtherItems etc.)
or moreItems
Although I think that even though you shouldn't make a habit of braking 'the rules' sometimes the best way to accomplish something may be to make an exception of the rule (Code Complete guidelines), and in your case, name the variable isNotLast
A simple semantic name would be last. This would allow code always positive code like:
if (item.last)
...
do {
...
} until (item.last);
Two issues to think about
What is the scope of the variable (in other words: are you speaking about a local variable or a field?) ?
A local variable has a narrower scope compared to a field. In particular, if the variable is used inside a relatively short method I would not care so much about its name. When the scope is large naming is more important.
I think there's an inherent conflict in the way you treat this variable. On the one hand you say "false when an object is the last in a list", where on the other hand you also want to call it "inFront". An object that is (not) last in the list does not strike me as (not) inFront. This I would go with isLast.