Re: [Sooc-devel] Changing class declaration paradigm

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

Ah, interesting little hang-up.

On Feb 24, 2008, at 4:36 PM, Mike Richman wrote:

> 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
>>
>>
> -------------------------------------------------------------------------
> 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