User : NamedTuple[user: str, email: str, group: str]
func anExampleFilterFunction(any_Tuple_including_User: NamedTuple[str,...]) -> bool
func filterByAFunction(iterable: List[NamedTuple[str,...]], filter_func: func) -> List[NamedTuple[str,...]]
func getValuesFromTupleByName(name: str, List[NamedTuple[str,..]]) -> List[str]
func sendEmails(email_list: List[str], msg: str, subject: str)
Less lines, less cruft, more modular and No objects.A bit off topic but note that... anExampleFilterFunction can be implemented to filter off of a User and a group at the same time or it can filter off of the email address itself. I could also compose filterByAFunction with itself in an innumerable amount of ways to produce any amount of custom filters:
//a, b, c are different filter functions.
filteredUsers: User = filterByAFunction(filterByAFunction(filterByAFunction(x, a), b), c)
//or
filterdUsers: User = filterByAFunction(x, func(y){ return a(y) && b(y) && c(y)})
The tricks(s) above cannot be done if I had everything encapsulated in objects. Objects are not compose-able. You cannot combine User or Group to create a UserAndGroup filter without explicitly defining a whole new class. Also in the end all a program really is doing is calling functions. Classes are just layers of cruft that have no meaning during execution.Plus even with it not meeting the requirements, it is confusingly presented, and is filled with terminology related to the implementation rather than the domain. Where's a group definition? How would you configure a filter for a group? Or a user for that matter. (Answer: you would require a much more complex data model, and functions to access and modify it).
I'll stick to OO for the top level paradigm I use until something better comes along.
OO being dead is fake news perpetuated by ignorant know-it-alls.
There is zero terminology related to implementation. NOT A single function was defined. All it is are function signatures analogous to your classes.
Read the pseudo code and understand it before you criticize there is enough information in the user tuple type to filter off of users and emails.
You think you are seeing over complexity but my code is actually more simpler and straightforward then your code. NOT to be insulting but you can't see it not because the code is complex but because you lack knowledge.
I'll tell you this. I completely understand your code and I completely understand my code. My judgement is less biased. Respond to me when your level of understanding reached mine.
Nothing gets my blood boiling more then deliberatr ignorance. Read and understand my code before you bitch.
Leading to an OO class design roughly like this: (there are other possible OO designs, but this illustrates the point)
// Send an email to a specific user or a group of user taking into account both user and group level filters.
sendEmail(Email, EmailDestination)
class Email {Title, Body, Attachments}
interface EmailDestination {
}class Group implements EmailDestination {
}class User implements EmailDestination {
}how would this look with a procedural design?