[sword-devel] :)

[Troy A. Griffitts]

Hey guys, thought you might find this amusing.  It's always good to get
pointers from the best. :)

_____________________________________

Subject: 
   Date: Wed, 5 Jan 2000 13:34:11 -0500 (EST)
   From: Bjarne Stroustrup
     To: scribe@crosswire.org




Date: Wed, 05 Jan 2000 03:22:53 -0700
From: "Troy A. Griffitts" <scribe@crosswire.org>
X-Accept-Language: en
MIME-Version: 1.0
Subject: inner class problem
Content-Transfer-Encoding: 7bit

Bjarne,
        I understand if you don't have time for this, but thought I'd
ask.
        I lead a GNU GPL project at: http://www.crosswire.org
[background
snipped and copied to the end]

        Borland extended C++ by adding a property mechanism to the
syntax, eg.

class TTreeView {
  TTreeNodes* FTreeNodes;
  __property TTreeNodes* Items = {read=FTreeNodes, write=SetTreeNodes};
  void SetTreeNodes(TTreeNodes* Value);
};

This allows one to specify a getter and setter for the property with
read and write (actual data storage, or methods with appropriate sigs)

This allows for things like:

treeView->Items->Clear();
treeView->Items = treeElements;
for (TTreeNodes *items = treeView->Items; items; items = items->Next())
etc.

We were hoping to duplicate this in our port with something like:
class TTreeView {
  TTreeNodes* FTreeNodes;

  class _Items {
  public:
    operator TTreeNodes* () {
      return FTreeNodes;
    }
    _Items &operator =(TTreeNodes* Value) {
      SetTreeNodes(Value);
      return this;
    }
  } Items;

  void SetTreeNodes(TTreeNodes* Value);
};


This does not work, but should give an idea of what we are trying to
achieve.  Any help would be greatly appreciated at this critical time in
the design.

        Thank you for your time,
                -Troy A. Griffitts


[background]
We are porting a subset of Borland's VCL Component library to gtk+
(actually we're planning on keeping references to implementation classes
which isolate the gtk+ code and hope to write a Qt implementation class
layer in the future.
===> I think that getting a non-proprietary "property" class would be
        important. I think you are on the right track, but that there is
a
        large number of details that needs to be addressed.

        First look at a simple example that I got to run:


// class TTreeView {
//   TTreeNodes* FTreeNodes;
//   __property TTreeNodes* Items = {read=FTreeNodes,
write=SetTreeNodes};
//   void SetTreeNodes(TTreeNodes* Value);
// };

#include<iostream>
using namespace std;

template<class Context, class T>
class _Items {
        Context* view;  // an Item needs to access values in its context
public:

        _Items(Context* v) :view(v) { }

        operator T() { return view->get(); }    // assume get() function
        T operator->() { return view->get(); }  // assume ste() function

        _Items& operator=(T Value) { view->set(Value); return *this; }
};

struct TTreeNodes {
        int val;
        TTreeNodes* next; 
        TTreeNodes() :val(0), next(0) { } 
        void Clear() { cout << "clear\n"; val = 0; }
        TTreeNodes* Next() { return next; }
};

class TTreeView {
  TTreeNodes* n;

public:

        void set(TTreeNodes* Value) { cout <<"set\n"; n = Value; }

        TTreeNodes* get() { return n; }

        _Items<TTreeView,TTreeNodes*> Items;    // items of type
TTreenodes* in a TTreeview

        TTreeView() :Items(this) { }    // give Items their context
        
};


int main()
{
        TTreeView* treeView = new TTreeView();
        TTreeNodes treeElements;

        treeView->Items->Clear();
        treeView->Items = &treeElements;
        for (TTreeNodes *i = treeView->Items; i; i = i->Next()) {
                cout << i->val << endl;
        }
        return 0;
}

I think a crucial design decision is how to parameterize _Item on
the set() and get() functions.

Your turn! (for comments, suggestions, problems, etc.)

        - Bjarne

Bjarne Stroustrup, AT&T Labs