Re: [Sooc-devel] Changing class declaration paradigm

[Daniel R. <sta...@gm...>]

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