nested classes style question

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

nested classes style question

John W. Eaton
Administrator
Back in the day, I thought nested classes were cool.  I thought using
them would help describe the structure of a program by saying "this
object is clearly part of this other object".  Maybe that's true when
the nested class is never used independently outside of the parent
class.  But now they just seem to serve to clutter class declarations
and cause a lot of extra overhead that doesn't add much clarity.

I'm thinking specifically of the scope and symbol_record classes that
are nested inside the symbol_table class.  Would anyone object to moving
the symbol_record and scope classes to separate files and declaring them
outside of the symbol_table class?  As far as I can see, backward
compatibility with the old symbol_table::scope or
symbol_table::symbol_record can be handled with a couple of typedefs.

Comments or suggestions?

jwe

Reply | Threaded
Open this post in threaded view
|

Re: nested classes style question

John W. Eaton
Administrator
On 11/16/2017 01:13 PM, John W. Eaton wrote:

> Back in the day, I thought nested classes were cool.  I thought using
> them would help describe the structure of a program by saying "this
> object is clearly part of this other object".  Maybe that's true when
> the nested class is never used independently outside of the parent
> class.  But now they just seem to serve to clutter class declarations
> and cause a lot of extra overhead that doesn't add much clarity.
>
> I'm thinking specifically of the scope and symbol_record classes that
> are nested inside the symbol_table class.  Would anyone object to moving
> the symbol_record and scope classes to separate files and declaring them
> outside of the symbol_table class?  As far as I can see, backward
> compatibility with the old symbol_table::scope or
> symbol_table::symbol_record can be handled with a couple of typedefs.
>
> Comments or suggestions?
>
> jwe

I pushed this changeset:

   http://hg.savannah.gnu.org/hgweb/octave/rev/3b302b2890d7

If there are any objections, we can discuss and change as needed.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: nested classes style question

Rik-4
In reply to this post by John W. Eaton
On 11/17/2017 09:00 AM, [hidden email] wrote:
Subject:
nested classes style question
From:
"John W. Eaton" [hidden email]
Date:
11/16/2017 10:13 AM
To:
Octave Maintainers List [hidden email]
List-Post:
[hidden email]
Content-Transfer-Encoding:
7bit
Precedence:
list
MIME-Version:
1.0
Message-ID:
[hidden email]
Content-Type:
text/plain; charset=utf-8; format=flowed
Message:
1

Back in the day, I thought nested classes were cool.  I thought using them would help describe the structure of a program by saying "this object is clearly part of this other object".  Maybe that's true when the nested class is never used independently outside of the parent class.  But now they just seem to serve to clutter class declarations and cause a lot of extra overhead that doesn't add much clarity.

I'm thinking specifically of the scope and symbol_record classes that are nested inside the symbol_table class.  Would anyone object to moving the symbol_record and scope classes to separate files and declaring them outside of the symbol_table class?  As far as I can see, backward compatibility with the old symbol_table::scope or symbol_table::symbol_record can be handled with a couple of typedefs.

Comments or suggestions?

Being a late comer to object oriented programming, I found the nested classes as yet one more confusing construct of a confusing new paradigm.  I'm better these days with ordinary classes, but I still don't see much advantage to nested classes.  No objection here to removing them.

--Rik

Reply | Threaded
Open this post in threaded view
|

Re: nested classes style question

Olaf Till-2
In reply to this post by John W. Eaton
On Thu, Nov 16, 2017 at 05:01:20PM -0500, John W. Eaton wrote:
> On 11/16/2017 01:13 PM, John W. Eaton wrote:
> >I'm thinking specifically of the scope and symbol_record classes that are
> >nested inside the symbol_table class.  Would anyone object to moving the
> >symbol_record and scope classes to separate files and declaring them
> >outside of the symbol_table class?  As far as I can see, backward
> >compatibility

I assume you mean backward compatibility with packages...

> >with the old symbol_table::scope or
> >symbol_table::symbol_record can be handled with a couple of typedefs.

Do you mean a header in core Octave with something like:

namespace octave
{
  // OCTAVE_DEPRECATED (...) ?
  typedef symbol_record symbol_table::symbol_record
  ...
}

?

Surely good to have something like this, but whether this is
sufficient for packages depends on how long it will be present in
Octave and on whether it's deprecated or not. Deprecated things tend
to be avoided by packages. And previous experience is that such
backwards compatibilities don't remain in Octave long enough to be
relied on by packages (those which support many Octave versions).

So this change is probably another one which has to be explicitely
cared for by packages supporting multiple Octave versions. But well,
it doesn't seem to add much effort. Of the maintained packages in
Octave Forge, only one references symbol_table::symbol_record, and
none references symbol_table::scope.

Summary: no objections...

Olaf

--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc (836 bytes) Download Attachment