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

1–10 of 150 posts

Re: Write More Classes

#2

Post by chewxy »

You can do the same with python's msgpack as the C# version

Try this:

    packer = msgpack.Packer()
    serialized = packer.pack('stuff you wanna pack')
      
    unpacker = msgpack.Unpacker()
    unpacker.feed(serialized)
    print unpacker.unpack()
I had originally used this, but then as my API scope extended to more than just using msgpack, having a common API interface for json (i.e. the .loads() and .dumps() method) was found to be more useful.

And while I agree with most of the article, I don't think writing more classes is a one-size-fits-all solution. Classes IMO, only makes sense from a heavily OOP point of view.

Re: Write More Classes

#3

Post by niggler »

chewxy wrote: post #2

You can do the same with python's msgpack as the C# version Try this: packer = msgpack.Packer() serialized = packer.pack('stuff you wanna pack') unpacker = msgpack.Unpacker() unpacker.feed(serialized) print unpacker.unpack() I had originally used this, but then as my API scope extended to more than just using msgpack, having a common API interface for json (i.e. the .loads() and .dumps() method) was found to be more…

I dont think the OP was pointing to OOP when talking about classes. You can have classes without a meaningful class hierarchy that still conforms to the OP's desired programming style using protocols like the iterator protocol.

A better way to phrase the OP's salient point while sidestepping the polemic of OOP is "Standardize and use protocols".

Re: Write More Classes

#5

Post by notallama »

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 write it once (i'm not saying haskell's records are nice, but they got that part right). same with rust.

and with a function, you write it once.

Re: Write More Classes

#7

Post by benrhughes »

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…

FWIW, with C#'s object initialisation syntax you can cut that down to once too. eg

  public class Foo
  {
     public string Bar { get; set;}
  }

  var foo = new Foo { Bar = "Hey there" };

Re: Write More Classes

#8

Post by redangstrom »

Seems like he's asking for modularization so we can make special-case adjustments to libraries without completely monkey patching or rewriting them. Seems like a reasonable ask of a mature library.

On the streaming verus resident working set argument... Most of what most programmers deal with doesn't have to scale to deal with huge streaming datasets, so it doesn't get the attention.

Re: Write More Classes

#9

Post by mafro »

Can anyone explain the statement about simplejson for me please?

  Some libraries manage to skip the token part. (I'm looking at you 
  simplejson, a library that even with the best intentions in mind 
  is impossible to teach stream processing)

Re: Write More Classes

#10

Post by comex »

IMO, the Flask example is pushing it - considering how large a job rendering a template is, the number of customization points is probably appropriate, but at some point you're going to get lost in a rabbit hole of wrapper functions that call wrapper functions and end up with three equally appropriate levels you might hook into because the code was written to keep you from having to duplicate a single line of code from the library in your alternative implementation-- never mind how confusing that makes things to the casual debugger (who wants to get to the actual meaty code to see what's wrong with it). Flexibility is useful, but it must justify the loss of simplicity.

But yes, in the JSON cases, having more flexibility than a single 'loads' is clearly justified.

Post reply on HN