octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Basic classdef functionality


From: Philipp Kutin
Subject: Re: Basic classdef functionality
Date: Fri, 26 Jul 2013 08:54:15 +0200

Hi jwe, Michael,


On Thu, Jul 25, 2013 at 8:49 PM, John W. Eaton <address@hidden> wrote:
> On 07/25/2013 02:42 PM, Philipp Kutin wrote:
>
>> As for the code
>> style, let's just assume that I wear huge rose-tinted glasses... oh
>> well ;).
>
>
> What is that supposed to mean?

Mostly just nitpicking about how I find the code hard to read. Sure,
it's a matter of personal preference and habituation, but I'll
explain.

First, the strange indentation. Here's a representative sample:

  if (pos == std::string::npos)
    retval = make_package (name, std::string ());
  else
    {
      std::string parent_name = name.substr (0, pos);

      retval = make_package (name, parent_name);
    }

IMO, indenting the braces halfway to the code of its surrounded block
effectively doubles the number of (imaginged) vertical lines, but adds
no information. Furthermore, the code in the "if" branch and the
"else" code are now indented differently, even they're at the same
"level"!

Then there's the curious spacing, for example:

  if (! arr.xelem (i).ok ())

For my taste, the first is right, but the three following are too
much. Personally, I tend to having spaces between tokens that are
connected with operators of low precedence. I mean, you wouldn't write
"a+b * c+d" either.

But as I said, it's all preference... in fact, I could easily nitpick
about certain stylistic aspects of some code which I otherwise
consider extraordinarily well-engineered software (LuaJIT,
http://luajit.org/).


On Thu, Jul 25, 2013 at 9:09 PM, Michael Goffioul
<address@hidden> wrote:
> Can I ask you whether you actually tested the classdef branch? Almost all
> "basic" features (if not all of them) that you listed in the initial mail
> are already supported. As you mentioned in that initial mail, having those
> features would make the classdef support tremendously useful. Though in the
> above you say that classdef seems very basic. Can I ask you what is(are) the
> missing feature(s) that transform the current classdef branch from
> tremendously useful to very basic?

At the time I wrote the reply, I had tested it for about ten minutes.
The apparent change of opinion (it's not) was partly due to too high
expectations, but also because I made a mistake: for testing, I
renamed an existing class M file and renamed the class name. But sure
enough, I forgot to rename the constructor and wondered why its code
wouldn't execute. Ouch! I will try to provide a more careful analysis
when I have played around with classdef a bit more.


--Philipp


reply via email to

[Prev in Thread] Current Thread [Next in Thread]