Re: [boost] Re: Re: Optional, tie, and iterator_adaptor

2003-09-02 Thread Mat Marcus
--On Monday, September 01, 2003 9:52 PM -0400 Brian McNamara <[EMAIL PROTECTED]> wrote: [snip] As a final aside, I think much of this thread is degenerating into Parkinson's Bicycle Shed[*], with respect to "is it a pointer/container/X?" At this point, I think we know what set of methods should

Re: [boost] Re: Re: Optional, tie, and iterator_adaptor

2003-09-02 Thread Brian McNamara
On Tue, Sep 02, 2003 at 09:05:59AM +0800, Joel de Guzman wrote: > My attempt to image "optional as conceptually a specialized but > nevertheless, *IS-A* T, with the added specialization that it can > be in a dead-uninitialized state." Is a feeble attempt to re-sell the idea > of the concept that w

Re: [boost] Re: Re: Optional, tie, and iterator_adaptor

2003-09-02 Thread Joel de Guzman
Mat Marcus <[EMAIL PROTECTED]> wrote: > --On Monday, September 01, 2003 3:37 PM -0300 Fernando Cacciola > <[EMAIL PROTECTED]> wrote: > >> Joel de Guzman <[EMAIL PROTECTED]> wrote in message >>> One can think of an optional as conceptually a specialized but >>> nevertheless, *IS-A* T, with the add

Re: [boost] Re: Re: Optional, tie, and iterator_adaptor

2003-09-01 Thread Joel de Guzman
Brian McNamara <[EMAIL PROTECTED]> wrote: > It's been pointed out before, but to re-emphasize it: from a > type-theoretic standpoint, it is not the case that optional-isa-T. > Rather T-isa-optional. (Dog-isa-Animal because Animal has more > possible values.) I don't mind the suggestive conceptua

Re: [boost] Re: Re: Optional, tie, and iterator_adaptor

2003-09-01 Thread Mat Marcus
--On Monday, September 01, 2003 3:37 PM -0300 Fernando Cacciola <[EMAIL PROTECTED]> wrote: Joel de Guzman <[EMAIL PROTECTED]> wrote in message One can think of an optional as conceptually a specialized but nevertheless, *IS-A* T, with the added specialization that it can be in a dead-uninitial

Re: [boost] Re: Re: Optional, tie, and iterator_adaptor

2003-09-01 Thread Joel de Guzman
Gregory Colvin <[EMAIL PROTECTED]> wrote: > On Monday, Sep 1, 2003, at 11:31 America/Denver, Joel de Guzman wrote: > >> Fernando Cacciola <[EMAIL PROTECTED]> wrote: >> >>> vector<>::begin returns an object with operators * and ->, >>> yet these objects are not pointers, and once that is learned,

Re: [boost] Re: Re: Optional, tie, and iterator_adaptor

2003-09-01 Thread Joel de Guzman
Fernando Cacciola <[EMAIL PROTECTED]> wrote: >> Even if I agree with you that an optional should not be a T, >> an optional is definitely not a pointer to T. >> > Definitely! > If HTML had blinking banners I think I'd use one to state this :-) Nor should it model a pointer. That was my point and

Re: [boost] Re: Re: Optional, tie, and iterator_adaptor

2003-09-01 Thread Gregory Colvin
On Monday, Sep 1, 2003, at 11:31 America/Denver, Joel de Guzman wrote: Fernando Cacciola <[EMAIL PROTECTED]> wrote: vector<>::begin returns an object with operators * and ->, yet these objects are not pointers, and once that is learned, people do not think they are pointers. Huh? pointer semantic

Re: [boost] Re: Re: Optional, tie, and iterator_adaptor

2003-09-01 Thread Mat Marcus
--On Monday, September 01, 2003 2:57 PM -0300 Fernando Cacciola <[EMAIL PROTECTED]> wrote: Mat Marcus <[EMAIL PROTECTED]> wrote in message [snip] After reading the documentation more carefully I learned that optional models pointer behavior. I spelled out how the code might look: boost::tie(*

[boost] Re: Re: Optional, tie, and iterator_adaptor

2003-09-01 Thread Fernando Cacciola
Joel de Guzman <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Brian McNamara <[EMAIL PROTECTED]> wrote: > > So I completely disagree that optionals should mix the interfaces of > > optional and the wrapped object into one. I think there should be an > > explicit unwrapping operation

[boost] Re: Re: Optional, tie, and iterator_adaptor

2003-09-01 Thread Fernando Cacciola
Brian McNamara <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > So I completely disagree that optionals should mix the interfaces of > optional and the wrapped object into one. I think there should be an > explicit unwrapping operation. But this is just my opinion, based on no > prac

[boost] Re: Re: Optional, tie, and iterator_adaptor

2003-09-01 Thread Fernando Cacciola
Brian McNamara <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On Sun, Aug 31, 2003 at 12:34:39AM -0700, Mat Marcus wrote: > [snipped] > > So, here's an idea for something completely new which maybe helps fit > your requirements. I start with the motivating example: > >PossUninit

[boost] Re: Re: Optional, tie, and iterator_adaptor

2003-09-01 Thread Fernando Cacciola
Mat Marcus <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > In this post I will put forward a use-case or two to help see whether > something a little different then the current version of optional > might be useful. I also begin making a case that a Concept like > PossiblyUninitialize

Re: [boost] Re: Re: Optional, tie, and iterator_adaptor

2003-09-01 Thread Joel de Guzman
Fernando Cacciola <[EMAIL PROTECTED]> wrote: > Joel de Guzman <[EMAIL PROTECTED]> wrote in message > Direct initialization: opt = 1 > seems right since this operation is never undefined. > This would mirror variant's interface. Ok. > Direct value accesing via implicit conversion: int i = opt > s

Re: [boost] Re: Re: Optional, tie, and iterator_adaptor

2003-09-01 Thread Joel de Guzman
Fernando Cacciola <[EMAIL PROTECTED]> wrote: > Joel de Guzman <[EMAIL PROTECTED]> wrote in message >> There's a lot of experience with it in other languages. Why not leverage >> that? Haskell::Maybe for instance. >> > Do you know of anything else besides Haskell? No. > I don't, and I took the t

[boost] Re: Re: Optional, tie, and iterator_adaptor

2003-09-01 Thread Fernando Cacciola
Brian McNamara <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On Mon, Sep 01, 2003 at 09:03:17AM +0800, Joel de Guzman wrote: > > Do it the ref, tuple and variant way: get(). But get(), as an > > element-access interface, should return a reference, not a pointer, as > > it does cur

Re: [boost] Re: Re: Optional, tie, and iterator_adaptor

2003-09-01 Thread Joel de Guzman
Fernando Cacciola <[EMAIL PROTECTED]> wrote: > vector<>::begin returns an object with operators * and ->, > yet these objects are not pointers, and once that is learned, > people do not think they are pointers. Huh? pointer semantics (behavior) does not mean that they have to be pointers. -- J

[boost] Re: Re: Optional, tie, and iterator_adaptor

2003-09-01 Thread Fernando Cacciola
Joel de Guzman <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Daniel Frey <[EMAIL PROTECTED]> wrote: > > Joel de Guzman wrote: > >> Although I don't see this as problematic: > >> > >> optional x; > >> if (x) > >> foo(x); > >> > >> Or perhaps: > >> > >> optional x

Re: [boost] Re: Re: Optional, tie, and iterator_adaptor

2003-09-01 Thread Joel de Guzman
Fernando Cacciola <[EMAIL PROTECTED]> wrote: > First of all, let's not confuse syntax with semantics. > optional<> HAS strict value semantics. No it does not. The accessors have pointer behavior! -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net ___

[boost] Re: Re: Optional, tie, and iterator_adaptor

2003-09-01 Thread Fernando Cacciola
Joel de Guzman <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Brian McNamara <[EMAIL PROTECTED]> wrote: > > > Offhand, the "pointer interface" for reading the value of an optional > > seems good to me. Being able to say > > > >optional x; > >... > >if( x ) foo( *x ); >

[boost] Re: Re: Optional, tie, and iterator_adaptor

2003-09-01 Thread Fernando Cacciola
Brian McNamara <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On Sun, Aug 31, 2003 at 09:58:45AM +0800, Joel de Guzman wrote: > > Fernando Cacciola <[EMAIL PROTECTED]> wrote: > > > Hi Mat, > > > > > > Thanks for the input. > > > > > > optional<> is now out on the field and it is the

[boost] Re: Re: Optional, tie, and iterator_adaptor

2003-09-01 Thread Fernando Cacciola
Joel de Guzman <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Fernando Cacciola <[EMAIL PROTECTED]> wrote: > > Hi Mat, > > > > Thanks for the input. > > > > optional<> is now out on the field and it is the only utility of its kind > > I've ever seen in C++, at least in real use. This