On Aug 13, 2:10 am, "Johan S. R. Nielsen" <j.s.r.niel...@mat.dtu.dk> wrote: > My primary objection is that for object-oriented ideology, I think > that constructors should specify what inherently _defines_ some > object. I don't think that the encoder/decoder algorithms do this for > a code.
Well, it depends on whether you're thinking of an error-correcting code from the perspective of a mathematician or the perspective of a communications engineer (like me). I tend to think of a code along with its encoder/decoder. To put it another way, one of the things I would like to do with a Code object is to encode/decode a message. For the Code object to support these messages, it needs to have an encoder and decoder as part of its *definition*. On the other hand, I'm not sure whether this functionality really belongs to a message vector, an Encoder/ Decoder object, or a Code object. I can see arguments for any one or several of these. In the end, I don't think it really matters. But it should be very easy to go from a Code to its encoder/decoder or vice versa. > ... snip ... > > A secondary objection is easily amendable: I think it is very > important according to Sage methodology, that the Code objects work > out-of-the-box for both encoding and decoding without the user having > to worry about different algorithms existing. This could of course be > done in your model by replacing the error-throwing with a sensible > default. If we want to amend the above idea, then we could let Code > classes have en/decode() functions which chooses, constructs, caches > and uses a sensible default algorithm. Voilá, and we arrive at my > idea :-) FYI, the error throwing is only for an *incorrect* request. As you suggest, the default can be provided based on the Code subclass. My approach included skipping the en/decoder altogether in case they were not needed but relatively expensive to construct. > So, I guess both ideas have the same flexibility and scalability, so > which to use is largely a matter of taste. I still like mine best, but > I gladly listen to arguments against it; I hope we can agree on > something. If you are as confused as it turned out I was when reading > your idea, I can quickly cook up some example-code ;-) I agree, it's a matter of taste. As long as both of them are in the same chapter in the reference manual (and some good examples in the cookbook), people shouldn't have too much trouble figuring out how to use them. It would be nice to come up with an approach so that the best default can be maintained simply even as the set of available En/Decoder's and Code class hierarchy grow somewhat independently. With my constructor approach, for example, adding a great new Decoder class could mean changing the constructor for every class that derives from Code. Of course, this can be avoided if we call the base class constructor carefully and consistently. In short, this automatic selection code could get messy, but I don't immediately see an advantage for your approach or mine. Enjoy! - Ryan -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
