5 ms·

How about "PasswordEntries" instead?

dalke 12y ago
That's more often used for a collection with random-access lookup, like a list of PasswordEntry instances. A specialized class might be indexed for lookups, as in: class PasswordEntries(object): def __init__(self, entries): self.entries = entries self._by_name = {entry.name: entry for entry in entries} # Also add lookup by uid, gid, etc. def __len__(self): return len(self.entries) def __getitem__(self, i): return self.entries[i] def get_name(self, name): return self._by_name.get(name) # other public lookup methods here entries = PasswordEntries(read_password_entries("/etc/passwd")) print "root uses", entries.get_name("root").shell print "_lp uses", entries.get_name("_lp").shell It's a bad name for a reader, which is more closely tied with I/O. The suffix "-reader" suggests support for file operations (like 'close()'), use as a context manager, and awareness that the values will only be available once. The suffix "-s" does not. At the very least it suggests that it's possible to start a new iteration over the complete container of entries. While you work to come up with a better name than "PasswdReader", what is your replacement name for "generator", as in: >>> def f(): ... yield 1 ... >>> x = f() >>> x <generator object f at 0x103ac3f50> >>> x.__class__ <type 'generator'> Your essay places the -or names into the -er category (they are, after all, indicators of action nouns), so why is "generator" a bad name?
- yegor256a 12y ago
  The idea of object-oriented programming is that you, a client of that reader, should NOT know that it reads from I/O. You should not rely on this information. You get a list of entries. Where they are coming from, either I/O, memory or a user console, is none of your business. It's an internal information of the object that gives them to you.
  - dalke 12y ago
    Your view is completely unsupported by the evidence. At some point you have to work with the filesystem, or the network, or other I/O systems. These have OO interfaces. According to you, these don't exist, or are somehow not OO. It's a purist attitude that does not fit reality. You must know the performance characteristics of your API. OO says nothing about performance. Sure, it's possible to have a random-access/list-like interface to a set of records ... on a file system, and assuming you're willing to take the initial hit for indexing should you want to seek to the end. But this assumes you are working with a file, and not a tape drive, socket, pipe, keyboard or other interface. It also assume that memory is infinite. You do not get a "list of entries", you get an iterator (notice the "-or"!) of records. A reader doesn't know if you have enough memory to provide a list. A list does, or it had to provide a lot of work to fake it. If you don't care about performance, memory constraints, latency, and other real-world factors then sure, your idealized world could do what you want. I don't live in that world, nor do you, nor does it seem that we'll get there in our lifetimes, nor does it seem reasonable to get rid of readers for the contexts I've mentioned, nor does it seem that people are confused by the "reader" suffix. Again, I ask for your names that distinguish between something which reads from a streaming interface (what I call a reader) and something which supports random access lookup (what I call a list). I gave code; they do different things. You suggsted "list" for the first one; what do you call them? I also asked you for what you think is the right name for a "generator".
    - yegor256a 12y ago
      Let's discuss one situation at a time. Which one bothers you most? The reader, the iterator, the generator or the list of entries? Give me one practical example of that -ER object and I'll show you how it can be refactored to get rid of this suffix and become more object oriented.
      - dalke 12y ago
        Is this a delaying tactic? I started with the reader, I gave working code named PasswdReader. You suggested the alternate name PasswdList so I replied with something that was a better fit to then name PasswdList, in large part because it had list-like performance characteristics. I think it's safe to assume that "reader" is the one that 'bothers me the most'. As for "practical", it's a simplification of code I use for parsing a chemical structure file into a sequence of records/molecule objects. I simplified it so it would fit in an HN comment and not require specialized domain knowledge. It does reflect the true intent of practical code. I'll be surprised if you can come up with a better name for "-Reader". Once that's done, I would like to read about your alternative name for "generator". But I can point to read-world OO interfaces like ANTLR at https://theantlrguy.atlassian.net/wiki/display/ANTLR4/Parse+Tree+Listeners https://theantlrguy.atlassian.net/wiki/display/ANTLR4/Parse+... which uses "ParseTreeListener", "JavaLexer", "JavaParser", and "ParseTreeWalker". It's much easier for me to believe you don't know what you are talking about than to believe that all of these "-er" classes reflect bad OO design.

dalke 12y ago

That's more often used for a collection with random-access lookup, like a list of PasswordEntry instances. A specialized class might be indexed for lookups, as in: class PasswordEntries(object): def __init__(self, entries): self.entries = entries self._by_name = {entry.name: entry for entry in entries} # Also add lookup by uid, gid, etc. def __len__(self): return len(self.entries) def __getitem__(self, i): return self.entries[i] def get_name(self, name): return self._by_name.get(name) # other public lookup methods here entries = PasswordEntries(read_password_entries("/etc/passwd")) print "root uses", entries.get_name("root").shell print "_lp uses", entries.get_name("_lp").shell It's a bad name for a reader, which is more closely tied with I/O. The suffix "-reader" suggests support for file operations (like 'close()'), use as a context manager, and awareness that the values will only be available once. The suffix "-s" does not. At the very least it suggests that it's possible to start a new iteration over the complete container of entries. While you work to come up with a better name than "PasswdReader", what is your replacement name for "generator", as in: >>> def f(): ... yield 1 ... >>> x = f() >>> x <generator object f at 0x103ac3f50> >>> x.__class__ <type 'generator'> Your essay places the -or names into the -er category (they are, after all, indicators of action nouns), so why is "generator" a bad name?

yegor256a 12y ago
The idea of object-oriented programming is that you, a client of that reader, should NOT know that it reads from I/O. You should not rely on this information. You get a list of entries. Where they are coming from, either I/O, memory or a user console, is none of your business. It's an internal information of the object that gives them to you.
- dalke 12y ago
  Your view is completely unsupported by the evidence. At some point you have to work with the filesystem, or the network, or other I/O systems. These have OO interfaces. According to you, these don't exist, or are somehow not OO. It's a purist attitude that does not fit reality. You must know the performance characteristics of your API. OO says nothing about performance. Sure, it's possible to have a random-access/list-like interface to a set of records ... on a file system, and assuming you're willing to take the initial hit for indexing should you want to seek to the end. But this assumes you are working with a file, and not a tape drive, socket, pipe, keyboard or other interface. It also assume that memory is infinite. You do not get a "list of entries", you get an iterator (notice the "-or"!) of records. A reader doesn't know if you have enough memory to provide a list. A list does, or it had to provide a lot of work to fake it. If you don't care about performance, memory constraints, latency, and other real-world factors then sure, your idealized world could do what you want. I don't live in that world, nor do you, nor does it seem that we'll get there in our lifetimes, nor does it seem reasonable to get rid of readers for the contexts I've mentioned, nor does it seem that people are confused by the "reader" suffix. Again, I ask for your names that distinguish between something which reads from a streaming interface (what I call a reader) and something which supports random access lookup (what I call a list). I gave code; they do different things. You suggsted "list" for the first one; what do you call them? I also asked you for what you think is the right name for a "generator".
  - yegor256a 12y ago
    Let's discuss one situation at a time. Which one bothers you most? The reader, the iterator, the generator or the list of entries? Give me one practical example of that -ER object and I'll show you how it can be refactored to get rid of this suffix and become more object oriented.
    - dalke 12y ago
      Is this a delaying tactic? I started with the reader, I gave working code named PasswdReader. You suggested the alternate name PasswdList so I replied with something that was a better fit to then name PasswdList, in large part because it had list-like performance characteristics. I think it's safe to assume that "reader" is the one that 'bothers me the most'. As for "practical", it's a simplification of code I use for parsing a chemical structure file into a sequence of records/molecule objects. I simplified it so it would fit in an HN comment and not require specialized domain knowledge. It does reflect the true intent of practical code. I'll be surprised if you can come up with a better name for "-Reader". Once that's done, I would like to read about your alternative name for "generator". But I can point to read-world OO interfaces like ANTLR at https://theantlrguy.atlassian.net/wiki/display/ANTLR4/Parse+Tree+Listeners https://theantlrguy.atlassian.net/wiki/display/ANTLR4/Parse+... which uses "ParseTreeListener", "JavaLexer", "JavaParser", and "ParseTreeWalker". It's much easier for me to believe you don't know what you are talking about than to believe that all of these "-er" classes reflect bad OO design.