[interfacekit] Re: Assignments page

Jeremy Rand wrote:

 > I took a look at the assignment page and picked a couple of things from
 > the outstanding list.  Could I have BPropertyInfo and BDeskbar assigned
 > to me?  Also, I noticed that BPoint and BRect are on the list of
 > outstanding tasks but there seems to be code for these in CVS.


Consider BPropertyInfo and BDeskBar yours.  I *swear* I won't haul off
and code one of them up one wacky afternoon. ;P

There are a number of classes which are not assigned, but that have code
in CVS.  These classes need to have documentation and tests written up
for them, and need to be code reviewed.

 > I have a question about the changes to the build and the removal of the
 > OpenBeOS namespace.  I was using that temporarily so that I could load
 > both OpenBeOS implementations and Be implementations of classes in the
 > same exec without symbol conflicts.  This was being used for testing
 > purposes so we could compare the Be implementation to ours very easily.
 > Plus, we probably need to link our test app against libbe.so to get
 > some basic functionality and I am not sure what the symbol conflicts
 > will lead to.
 >
 > With the namespace removal, how are we addressing these issues?  I
 > don't necessarily disagree with the removal but I am not sure how this
 > affects our ability to test the code we are writing.


These are great points.  What I have found is that using the OpenBeOS
namespace really only works for classes that are basically stand-alone.
   In particular, I first ran into this when I tried to test BButton --
BWindow was not happy about trying to set OpenBeOS::BButton as the
default button.  Anything that takes a BHandler, for example, is not
going to be happy with OpenBeOS::BHandler.  And etc.

I did some simple testing with BArchivable and it seemed to work alright
even when libopenbeos.so was linking against libbe.so.  I don't know how
well that will hold up at a larger scale, though; we could try doing 
more in depth tests with this to determine if it is a viable 
methodology.  I also experimented with a pass-through library which 
worked to a certain extent, but then I ran into problems with 
contructors and destructors -- default constructors being needed when 
they weren't available, and constructors and destructors getting called 
twice (never a good thing).

Classes which are not dependent on other classes in the hierarchy are 
relatively easy to test regardless of whether the namespace it there or 
not.  For my BArchivable tests (which, for some odd reason, seem to not 
be in CVS anymore), I simply created two makefiles, one which links to 
libopenbeos.so and one that links to libbe.so.

For my part, I'm trying to build up the foundation layers of the 
hierarchy as fast as possible to try and make the whole point moot. =) 
In the meantime, if the only way to really test your code is to use the 
namespace, then please go ahead.  Do remember though, that once the Be, 
Inc. implementation has been tested (to see how it works), there really 
isn't a need to test it again, much less be able to test both in the 
same test run.  So if it takes a little effort to reconfigure for those 
tests, I don't think that's a big loss.

e

 > Thanks.
 >
 >
 >>In an effort to make information about what tasks are assigned (and to
 >>whom they are assigned) and what tasks are unassigned, I have added an
 >>"Assignments" page to the team site.  It's pretty basic right now;
 >>
 > I'll
 >
 >>wire it all up with links in the next day or two.  There is a link
 >>
 > right
 >
 >>off of the index page to it.  Everyone please take a quick look and
 >>
 > make
 >
 >>sure I've got your assignments correct; I'd hate to have a repeat of
 >>
 > me
 >
 >>taking Jeremy's assignment. =P
 >>
 >>Speaking of assignments and Jeremy, he's the only one I heard from on
 >>
 > my
 >
 >>last call for check ins and status.  What's going on, folks?  Check
 >>
 > that
 >
 >>code in, regardless of the state it's in, and tell me how things are
 >>going -- even if it's just to say "I have no time right now because of
 >>real life". ;)
 >>
 >>To those who have no assignment:  I will be culling the mailing list
 >>
 > and
 >
 >>the team roster next Monday, April 22.  Unless you are new to the
 >>
 > team,
 >
 >>you will be quietly removed.  If this is the only team you're on,
 >>
 > being
 >
 >>removed from the roster will likely also mean loss of repository
 >>check-in priviledges.  Approved lurkers are obviously exempt.
 >>
 >>Thanks,
 >>
 >>e
 >>
 >>Necessity is the plea for every infringement of human freedom. It is
 >>
 > the
 >
 >>argument of tyrants; it is the creed of slaves.
 >>     -William Pitt, British prime-minister (1759-1806)
 >>
 >>
 >>
 >>
 > --
 > Jeremy Rand
 > jrand@xxxxxxxx
 >
 >
 >

Other related posts: