Re: Fwd: Re: Fwd: Considering adding a "dispatch" function for compile-time polymorphism

[David Spies]

On Fri, Aug 15, 2014 at 7:51 AM, Jordi Gutiérrez Hermoso <address@hidden> wrote:

On Fri, 2014-08-15 at 05:16 -0600, David Spies wrote:
> It's true I feel somewhat like my code is being over-scrutinized.  In
> particular, I don't see the purpose of nitpicking over the names of
> "private" functions that aren't intended for external use.

Other people have to read your code. It's not for you right now. It's
not for the computer (the computer is just as happy with unreadable
assembler). It's for us. We have to be able to understand 10 years
from now when we read this what was going on in your mind. This
includes your future self.

I agree, but we already went through a round of renaming on the "find" methods at the beginning of the summer when there was time to change them.  Why not address these problems the first time around?

    There has to be a better name than "find_to_R".  Just "find" would
    be better.  Most functions do something and store the result in some
    object, but they are not all named VERB_to_OBJECT and naming
    something that way does not help with understanding.

There already is a "find".

With the same signature?

There's no argument that the code for "find" becomes more readable when you change all the internal private method names to find.  The one method I named "find" is the one that represents the public interface to be called.  If anyone wants to make changes to the find implementation in the future, it will be easier for them if they can distinguish between the different methods by name.  If all of them are named "find", then figuring out which call refers to which definition is a lost cause

It really is not worth arguing over function names, just change them.

I do and I did wherever I could.  But suggestions such as "find_result should be changed to result" are ignoring such details as there's also an "ffind_result". "find_result" is the type R, used in Octave C++'s internal "find" while "ffind_result" is the type used by the interpreter's "Ffind".

If I named them both "result", then that would cause compiler problems since struct names can't be overloaded.

Regardless, I understand that even if I disagree, I should still defer to John as the ultimate authority on how things should be named.
But suggestions such as

Names like dir_to_template don't tell me much.  The purpose of this function is what? [continues on to guess correctly what the function does, but does not suggest a better name in that case]

aren't much help in that department because I don't know what constitutes "better" if I'm not already on the same boat philosophically

There is, sort of, an existing Octave style. Stick to it. Such
bikeshedding battles are not worth fighting. When I contribute to any
project, including Octave, I follow the existing style. Each project
has its own style and the people in it have a particular idea of some
basic idioms of how things ought to be done.

 

Octave's existing code doesn't have boilerplate template-coercing methods because the existing code chooses to copy-paste wherever possible rather than look for intelligent ways to handle those few sections where methods "ab" and "ac" diverge (despite the last paragraph in http://www.gnu.org/software/octave/doc/interpreter/C_002b_002b-Sources.html#C_002b_002b-Sources).

Octave's existing style doesn't include namespaces, or any serious use of templates.  During my project, I wrote generic methods that properly handle full arrays, sparse arrays, diagonal matrices, and permutation matrices. AFAICT the rest of Octave does not do that anywhere.  Most of Octave just fails with an OOM when trying to handle a large permutation or diagonal matrix, because no author ever seems to bother with the "what-if's" associated with each of the possible argument-types.  In fact, there are plenty of Octave methods which instead will happily attempt to compute the linear index as an octave_idx_type, overflow, and give incorrect results instead.

Scott Meyers says C++ is a combination of four languages: Object Oriented C++, old low-level C, generic template C++, and STL.
Octave doesn't have any generic template C++ in it currently, so it hasn't had to make any of the associated naming decisions.

> However I have made quite a few changes in response to John's
> reviews. As a rule of thumb, anything I don't protest or just
> respond with an "Okay" is a change I made (it may be hard to tell
> from the revision history sometimes since I use hg amend to fix it
> because all this code is so far back).

It's possible to see those past editions by doing

    hg log -r --hidden 'allprecursors($revision)'

where $revision is the revision whose past editions you want to study.
If you want to see the differences between any two of them, do as
usual

    hg diff -r --hidden $rev1 $rev2

> However, it's hard to make major interface changes at this point
> (such as embedding the direction in the iterator type itself rather
> than making it a template parameter of the step function) because
> all the rest of the code I've written for this project relies on the
> interface as it is now.

This seems problematic. Already, so soon into development, we're
locked into a particular way of doing things, a way that can't be
changed easily? The whole point of this summer project was to change
how things were done.

It's not soon into development.  The hard pencils-down deadline is Monday.  GSoC is over.  The entire summer, the last line of every email I sent to John was "have you looked at find yet?".  It's the first thing I said every time I logged onto IRC after "Hi jwe".  And he never once responded to it.  It's why I told you "my code will just get thrown away".  Because I knew in the end it would come down to the wire and there simply wouldn't be time for the massive overhaul of all my code that John would require before accepting it.  Even now, he still he hasn't looked at any of the iterator code, he hasn't looked at my approach to sparse-matrix indexing (which was the ultimate goal of this project), and he hasn't looked at the extra protection afforded by --enable-uniqueness-checking and --enable-bounds-checking.  He hasn't reviewed anything I've done beyond the first week.

We're still discussing the first 5% of the code I wrote this summer.  Am I supposed to believe that when John gets around to reviewing the other 95% (today, tomorrow, I guess?  I don't know?), there won't be the same density of problems with it?

This is a failed GSoC project.  There isn't anything you or I can do now that will change that.