From: David Abrahams (abrahams_at_[hidden])
Date: 2000-10-11 09:02:07
----- Original Message -----
From: "Gary Powell" <Gary.Powell_at_[hidden]>
> > One of us is completely nuts ;->. How can I move the test
> > (is_prefix(enablers[i].name + 2, name + 2)) outside the loop if it
> > on the loop index, i?
> name += 2;
> if (is_prefix(enablers[i].name + 2, name))
I see now. I guess I should stop pussyfooting and either go for optimization
or clarity here, eh?
> > Naming details and boostification are still pending. Since the library
> > itself has yet to get a final name (What's your vote?) it would be
> > premature to select namespaces, I think.
> > > If and when py_c++ becomes part of the standard, won't we have a
> > problem
> > > with the class names "String" and "Tuple" (I'm assuming that Jaakko
> > Jarvi's
> > > Tuple will also make the grade.)
> > Not if they're properly namespace scoped ;->
> I'm of the school that is planning on all boost libraries becoming part of
> "std". I suppose that a c++ to python interface isn't as likely a
> as Tuple is for general inclusion but it would be nice to get the code
> so that it doesn't preclude it.
I'm of the school that hopes-to-whatever-higher-power-you-choose that std::
adopts some sub-namespaces as the standard library grows. Can you imagine
the Java library all in one big namespace?
> Re: Object
> It one of those class names that is so overused to invite all future non
> use. It's name has become almost meaningless unless there is some other
> of information attached. That's why I favor PyPtrObject 'cause that's what
> it is.
Sorry, I still appeal to the motivation above on this one.
> Re: Dict
> Why abbreviate this? Code is read 5 or 6 times for every time its
> written. The few extra characters don't affect compile time or program
> speed. It's part of my personal goal of write what you mean, name them
> they are.
I completely agree. Abbrevs rub me the wrong way, 2 ;->
> Again these are my opinions and can be freely disregarded.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk