Re: [Sooc-devel] Changing class declaration paradigm

[Mike R. <mik...@gm...>]

I just thought of one additional problem.  Right now, we tell Doxygen
that

s_class (Derived, Base)

means

class Derived : Base

With the new way, it will be rather more complicated to get Doxygen to
play nice with our classes.  Still, I think that with an appropraite
Doxygen preprocessor script, it should be doable.  I think it in a
sacrafice I am willing to make.

I'll let you know when I take care of it.

-Mike

On Sun, Feb 24, 2008 at 3:50 PM, Daniel Reinish <sta...@gm...> wrote:
> I'm not directly familiar with the structural changes that had to take place
> to make that system work.  However, if reverting to the old technique will
> enable "always-on" data hiding as well as a system for wrapping messages in
> methods, those sound to me like two major reasons to do so.  As you have
> pointed out before, the methods that get written for conveniently accessing
> the messages are rather inelegant.  Furthermore, it has come to my attention
> in various conversations with you that data hiding has been a major headache
> for quite some time.  That is rather unfortunate since it is a core
> principle of OO programming.  Thus, while I'm kind of sad to see the loss of
> this aesthetically pleasing technique (which happens to bear a rather
> convenient resemblance to the way classes are defined in Objective-C), I can
> certainly understand the motivations to do away with it.
>
> An additional benefit that you have not mentioned is that it makes the
> meaning behind the declaration far more explicit.  That is to say, the line
> "s_class (SObject, SBase)" for instance, does not inherently tell anything
> to the reader.  In particular, deeper into the class hierarchy, it may not
> be entirely evident who is inheriting from whom.  Explicit #define
> statements make it incredibly obvious which class is the current one and
> which is the parent.  Having the words SType and SParent in the code is kind
> of unfortunate because it is not something one normally works with directly,
> but it is not altogether unreasonable or impractical.
>
> I really agree with you that the only significant con is that it doesn't
> look as nice and/or clever .  You have implied in your explanation that
> reverting to the #define statements opens up a ton of additional
> flexibility.  I would say that sacrificing prettiness that has resulted in
> some major roadblocks in the name of increased flexibility is a reasonable
> direction to go at this point, given that you have tried nearly everything
> imaginable to get around some of those roadblocks with little success.  If
> the resulting technique were incredibly ugly, I'd have a problem with it.
> Two #define statements and the resulting removal of the explicit SHide
> business definitely does not fall into the category of incredibly ugly.
>
> Furthermore, I believe the underlying implementation could certainly do with
> some simplification.  This is Simple Object-Oriented C, after all—and all
> those preprocessor macros and such are pretty crazy from my perspective.
>
> So, in conclusion, I support your decision.  And, as this is part of the
> library's core functionality, this will obviously be something that needs to
> be accomplished before we tackle a Sooc implementation of Polar Connection
> or any other software.
>
> Good luck!
>
> --Dan
>
>
>
> On Feb 24, 2008, at 4:05 AM, Mike Richman wrote:
>
>
> It has become clear to me that the current mechanism for class
> declaration is no longer viable.  While code like
>
> s_class (Derived, Base) {
>         ....
> };
>
> has a certain aesthetic appeal, it is no longer worth while.  I'm
> still proud of the tricks I used to make it work, but ultimately the
> following will prove more effective and simple -- and thus in line
> with the principles of Sooc:
>
> #define SType SObject
> #define SParent SBase
> s_class {
>         ...
> };
>
> Pros:
> Will allow new techniques for wrapping messages in methods conveniently.
> Will simplify the underlying implementation by reducing the need for
> redundancy such as obscure pointers to Sooc-instantiated functions.
> Will not require the header author additionally to "#define SHide
> MyType" in order to enable data hiding; hence data hiding will always
> be possible.
> Will enable more flexible section ordering of s_class, etc. blocks.
> Probably the only requirement will be that methods (not members) come
> first, which is simpler and more sensible than the current required
> order.  This will also allow somewhat less memory to be used by class
> metadata structures.
> Will potentially allow more flexible expansion that is not yet
> foreseen (indeed, failure to foresee the issues we are confronting to
> day is part of what led us to believe that the existing system was
> viable)
>
> Cons:
> Somewhat less cute.
>
> I think this top-of-the-head list is more than sufficient to show that
> we should revert to the #define technique that we used once upon a
> time.  If you have anything to add to the pro/con list, do let me
> know.  I will try to make this [fairly drastic] change in the near
> future.
>
> -Mike
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Sooc-devel mailing list
> Soo...@li...
> https://lists.sourceforge.net/lists/listinfo/sooc-devel
>
>
> -------------------------------------------------------------------------
>  This SF.net email is sponsored by: Microsoft
>  Defy all challenges. Microsoft(R) Visual Studio 2008.
>  http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
>  Sooc-devel mailing list
>  Soo...@li...
>  https://lists.sourceforge.net/lists/listinfo/sooc-devel
>
>