Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Write More Classes

lucumr.pocoo.org

Post reply on HN
Print view View original

131–140 of 150 posts

Re: Write More Classes

#131

Post by nessus42 »

dragonwriter wrote: post #128
nessus42 wrote: post #124

Earlier quoted context omitted.

> You can still break up your algorithm into a class with multiple template methods Template methods are an abomination. They are only widely used because many OO languages don't have first-class functions. A template method means that the method is being parameterized by one or more functions. Parameters should be expressed as parameters ! You wouldn't design a Circle class so that you need to subclass it to specify…

> Furthermore, it is not safe to override a method without knowing if it has been designed for overriding, and what the class expects of the overriding method. This is true, but likewise, its not safe to parameterize functionality by passing callbacks unless you know what the function you are passing the callback to expects of callback functions (in terms of arguments, return values, and side effects.) Both of these,…

> This is true, but likewise, its not safe to parameterize functionality by passing callbacks unless you know what the function you are passing the callback to expects of callback functions

Of course; this goes without saying. But when programming in an OO style, programmers often override methods thinking that they are only changing the behavior of that one method, when in fact they could be inadvertently changing the behavior of other methods in the class.

When passing in functions as arguments, on the other hand, this makes it much more explicit what is supported and what isn't.

Re: Write More Classes

#132

Post by lutusp »

nessus42 wrote: post #129
lutusp wrote: post #127

Earlier quoted context omitted.

> Here, here! Where, where? ITYM "Hear! Hear!" http://en.wikipedia.org/wiki/Hear,_hear "Hear, hear is an expression used as a short, repeated form of hear him, hear him. It represents a listener's agreement with the point being made by a speaker."

Yes, I know, but it's not nice to mess with the lysdexics.

:) I would have let it go, but a lot of young people read HN and I didn't want them to think the expression really was "Here! Here!" Once these things get started ...

Re: Write More Classes

#133

Post by barrkel »

lucian1900 wrote: post #59
barrkel wrote: post #27

Earlier quoted context omitted.

From what you wrote, I'm not sure you read the article. It's not about objects vs functions; it's about hiding a lot of functionality behind an overly-simple interface, with particular attention paid to an example of a parser that takes a whole string rather than a streaming interface. What annoyed me most was his constant apparent conflation between bytes and characters. But I didn't really see much evidence of trea…

I saw no conflation. Everything there is a byte.

Quote:

For instance while I have not yet reached the end of the string I would feed my characters into a buffer until I found the end of the string

The point however is that instead of reading characters step by step some lexers will instead have a look at a buffer of a certain size and move a pointer around in that buffer and modify some bytes in place (in-situ).

He talks about this buffer, at one moment in terms of bytes, another moment in terms of characters.

It's a pedantic quibble, but an easy source of errors, especially if you're using a language that doesn't distinguish strongly between the two concepts, and e.g. you encode your characters as UTF8 with a weak alias to unsigned char just like bytes.

Re: Write More Classes

#134

Post by dragonwriter »

nessus42 wrote: post #131
dragonwriter wrote: post #128

Earlier quoted context omitted.

> Furthermore, it is not safe to override a method without knowing if it has been designed for overriding, and what the class expects of the overriding method. This is true, but likewise, its not safe to parameterize functionality by passing callbacks unless you know what the function you are passing the callback to expects of callback functions (in terms of arguments, return values, and side effects.) Both of these,…

> This is true, but likewise, its not safe to parameterize functionality by passing callbacks unless you know what the function you are passing the callback to expects of callback functions Of course; this goes without saying. But when programming in an OO style, programmers often override methods thinking that they are only changing the behavior of that one method, when in fact they could be inadvertently changing t…

> Of course; this goes without saying. But when programming in an OO style, programmers often override methods thinking that they are only changing the behavior of that one method

This is not a problem with using classes or overriding methods, its a problem either with either failure to document behavior on the part of the library author or failure to read documentatio on the part of the library consumer.

Neither of those is any less a danger in the case here the design of the library involves parameterizing functionality by passing functions around as parameters.

Re: Write More Classes

#135

Post by CodeMage »

loup-vaillant wrote: post #113
CodeMage wrote: post #100

Earlier quoted context omitted.

The question is, what classes do that module systems don't? Modules (at least in Python) are singletons.

Doesn't count. When you define a single data structure in a module, (along with functions to manipulate it) you can instantiate it just like you would a class.

Ugh. That's like saying that high-level programming languages "don't count" because you can do that stuff in assembler.

Re: Write More Classes

#136

Post by nessus42 »

dragonwriter wrote: post #134
nessus42 wrote: post #131

Earlier quoted context omitted.

> This is true, but likewise, its not safe to parameterize functionality by passing callbacks unless you know what the function you are passing the callback to expects of callback functions Of course; this goes without saying. But when programming in an OO style, programmers often override methods thinking that they are only changing the behavior of that one method, when in fact they could be inadvertently changing t…

> Of course; this goes without saying. But when programming in an OO style, programmers often override methods thinking that they are only changing the behavior of that one method This is not a problem with using classes or overriding methods, its a problem either with either failure to document behavior on the part of the library author or failure to read documentatio on the part of the library consumer. Neither of…

> This is not a problem with using classes or overriding methods, its a problem either with either failure to document behavior on the part of the library author or failure to read documentation on the part of the library consumer.

Missing or poor documentation is a sad reality of programming in the real world. And is the normal state when working on a active project with other developers. This would be mitigated if programmers were very careful about declaring methods to be final if it's not perfectly safe to override them, but most are not that careful, or even fully aware of the issues. And in many programming languages there is no way to declare a method to be final.

> Neither of those is any less a danger in the case here the design of the library involves parameterizing functionality by passing functions around as parameters.

When programming in a functional style, functionality that is not intended to be modified by the client will not provide a parameter for doing so, so this significant source of confusion is eliminated.

Re: Write More Classes

#137

Post by dragonwriter »

notallama wrote: post #5

if classes didn't have such a terribly verbose syntax in basically every language that has them, i'd be less opposed to using them. in java, c++, or c#, to add a variable to a class, you have to repeat its name 4 times. once to declare, once in the constructor parameters, and once on each side of the assignment. why am i writing the same thing 4 times for what should be a core part of the language? in haskell, you wr…

> in java, c++, or c#, to add a variable to a class, you have to repeat its name 4 times. once to declare, once in the constructor parameters, and once on each side of the assignment. why am i writing the same thing 4 times for what should be a core part of the language?

Because Java, C++, and C# suck at this. I'm trying to see the relevance to the OP, which is about Python, which rather decidedly lacks this problem. To add a new instance variable in a class, you need to mention it once, or twice if your using a __slots__-based class for compact memory footprint (because then you have to add it to __slots__ and then actually assign it a value somewhere.)

Re: Write More Classes

#138

Post by aidos »

stonemetal wrote: post #80
aidos wrote: post #78

Earlier quoted context omitted.

The quote posted in the initial comment really has no relevance to Armin's article so it's fair enough to call it out in this context. To attack the quote itself by simply assuming the author is inexperienced in OO just silly. Particularly so, given that Joe Armstrong has a grasp of computer languages that most of us could only ever dream of.

To attack the quote itself by simply assuming the author is inexperienced in OO just silly. No one is assuming anything about his OO skills, they are reading the words written and assuming the author isn't lying.

Erm, really?

Love it when people write about OO without OO experience.

Re: Write More Classes

#139

Post by loup-vaillant »

CodeMage wrote: post #135
loup-vaillant wrote: post #113

Earlier quoted context omitted.

Doesn't count. When you define a single data structure in a module, (along with functions to manipulate it) you can instantiate it just like you would a class.

Ugh. That's like saying that high-level programming languages "don't count" because you can do that stuff in assembler.

I'm not arguing Turing completeness here. I'm arguing trivial one to one mapping. Syntax sugar. Compare:

  struct foo {
    int   bar;
    float baz;
  };
  int   get_bar(foo);
  float get_baz(foo);
Which would emulate this:

  class foo {
  public:
    int   get_bar();
    float get_baz();
  private:
    int   bar;
    float baz;
  };
If you're interested, I wrote more about that here: http://loup-vaillant.fr/articles/classes-as-syntactic-sugar

Re: Write More Classes

#140

Post by dragonwriter »

nessus42 wrote: post #136
dragonwriter wrote: post #134

Earlier quoted context omitted.

> Of course; this goes without saying. But when programming in an OO style, programmers often override methods thinking that they are only changing the behavior of that one method This is not a problem with using classes or overriding methods, its a problem either with either failure to document behavior on the part of the library author or failure to read documentatio on the part of the library consumer. Neither of…

> This is not a problem with using classes or overriding methods, its a problem either with either failure to document behavior on the part of the library author or failure to read documentation on the part of the library consumer. Missing or poor documentation is a sad reality of programming in the real world. And is the normal state when working on a active project with other developers. This would be mitigated if…

> This would be mitigated if programmers were very careful about declaring methods to be final if it's not perfectly safe to override them

Its always perfectly safe to override a method if you maintain its required features. Its rarely, if ever, perfectly safe to do so if you don't. The issue is correctly documenting the required features.

Post reply on HN