None of the materials you listed are fluorinated polymers.

EDIT:

If you meant that I cant turn PEEK into a plastic (as in having plasticity) - sure.

But read my comment carefully. Im not saying fluorinated polymers don't have their use cases. Im just saying that for many (but not all!) applications of perfluorinated polymers, there are alternative ways of doing things. For example wool and stainless steel make excellent alternatives for jackets and frying pans.

Should nuclear (re)processing plants ditch teflon when dealing with UF6? Probably not. Should my gas fittings need teflon tape? No, alternatives exist.

This would be true if the products were clearly labelled, and safer existing alternatives weren’t pulled off the market by centralized decision makers at large companies.

As it is, if you buy a “ceramic” pan, you get some teflon knockoff instead of Le Creuset style stuff.

I'm not sure how that would work exactly, but sure if customers were properly informed and knew what they were buying had such bad side effects some of the blame would land on them.

That'd be a hard sell though since it seems like part of the issue was manufacturers burying research and denying any knowledge of problems while selling these chemicals as a miracle cure of sorts

Sure - the *Client would be a class or library intended for import/use by consumers of a resource exposed by a service. The exposed API should be viewed as usable independently, but it can sometimes be useful to add a layer of abstraction via a Client to would hold any logic required for interacting with a specific API.

Say you have an API that lets you bulk fetch an Item (`getItems(Collection<UUID> itemIds, int pageNumber, int pageSize)`), but the API enforces pagination and also requires authentication. A Client could require instantiation with whatever is required for authentication (`ic = new ItemClient(authToken)`), and provide a method to retrieve a huge list of Items without worrying about pagination (`ic.getItems(itemIds)`).