[rickbad68]

This trivial example does not illustrate the usefulness of OO design. Extending the example imagine the requirement is that the target of an email may be either a single user or a group of users, and in addition, email filters can be configured for both individual users and groups of users

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 {

   Iterator<User> getRecipients(Email); 
   List<Filter> getFilters();

}

class Group implements EmailDestination {

   // returns group filters
   List<Filters> getFilters();                 
   List<User> getMembers();

   // returns all recipients after applying group and 
   // individual recipient filters
   List<User> getRecipients(Email);  

}

class User implements EmailDestination {

   // returns user specific filters.
   List<Filters> getFilters();                          

   // returns itself unless filtered
   Iterator<User> getRecipients(Email);   

}

how would this look with a procedural design?

[crimsonalucard]

Your example has a globally defined function sendEmail. Big OOP languages such as java or C# do not permit that style. You must define all functions as a method of an object if you want to follow the OOP style. You are illustrating a hybrid style of procedural and OO.

    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.

[rickbad68]

But the requirements were to allow filters to be configured on users and groups, which would require more info in your data structures. This doesn't meet the specified requirements.

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.

[crimsonalucard]

Dude. Your group definition Is based on how you define your filter function. That is essentially a group. Users are filtered off the group string in which they belong. Read the code before you respond like a child.

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.