🚀 go-pugleaf

In article <27634@netnews.upenn.edu> limsoon@saul.cis.upenn.edu.UUCP (Limsoon Wong) writes:
 
>the program below is a contrived one.   it cannot  be compiled.
>the reason is a type fault. however, it exhibits a very central
>characteristic of update.    something should be  done to allow
>this kinds of programs.	   			    ---limsoon.

I disagree completely that such programs should be allowed.  Since test()
returns a `a&', basically what you are asking is that there be a implicit
conversion from a base class to a derived class.  No way should this be
allowed.  If you really want the below program to work, one possibility
would be to add the following constructor definitions to the class
declaration of b:

	 b() {};
	 b(a) {};
 

-- 
Mike Lijewski  (H)607/277-0394 (W)607/254-8686
Cornell National Supercomputer Facility
ARPA: mjlx@eagle.cnsf.cornell.edu  BITNET: mjlx@cornellf.bitnet
SMAIL:  1122 Ellis Hollow Rd. Ithaca, NY  14850

In article <27634@netnews.upenn.edu> limsoon@saul.cis.upenn.edu.UUCP (Limsoon Wong) writes:
>
>the program below is a contrived one.   it cannot  be compiled.
>the reason is a type fault. however, it exhibits a very central
>characteristic of update.    something should be  done to allow
>this kinds of programs.	   			    ---limsoon.
>
>#include <stream.h>
>class a { 
>  public: 
>    a& test() { 
>	// do some modification to the state of this object,
>	// then ...
>	return *this;
>};
>class b : public a { 
>  public:
>    int b;
>};
>main() { 
>  b B; 
>  B = B.test();
>  // type violation despite the fact that 
>  // `B' and `B.test()' are the same object.
>}

I for one do not see where 'B' and 'B.test()' are the same object. The
function B.test() clearly returns a reference to an 'a' object. What
you could do is:

class b : public a { 
  public:
    int b;
    b &test() { a::test(); return *this; }
};

(Forgive me if the syntax is not correct)

I understand your point of view though, and I think it would be nice
if there was some construct in C++ to do what you want. I know some of
my classes could use it. Maybe something like:

class a { 
  public: 
    virtual& test() { 
	// do some modification to the state of this object,
	// then ...
	return *this;
};

In otherwords, make the return type 'virtual' like functions. 
In this case, the virtual means the type of the class. So when class
'b' is derived from class 'a', all virtual return types in class 'a'
will now return type 'b'.

Of course this we be very ugly to implement, and is sort of like
parametric return types. 

Actually, would templates solve this problem?

Roland
-- 
Roland J. Schemers III                              Systems Programmer 
schemers@vela.acs.oakland.edu (Ultrix)              Oakland University 
schemers@argo.acs.oakland.edu (VMS)                 Rochester, MI 48309-4401
"Get off your LEF and do something!"                (313)-370-4323

In article <10599@batcomputer.tn.cornell.edu> lijewski@tcgould.tn.cornell.edu (Mike Lijewski) writes:
>In article <27634@netnews.upenn.edu> limsoon@saul.cis.upenn.edu.UUCP (Limsoon Wong) writes:
> 
>>the program below is a contrived one.   it cannot  be compiled.
>>the reason is a type fault. however, it exhibits a very central
>>characteristic of update.    something should be  done to allow
>>this kinds of programs.	   			    ---limsoon.
>
>I disagree completely that such programs should be allowed.  Since test()
>returns a `a&', basically what you are asking is that there be a implicit
>conversion from a base class to a derived class.  No way should this be
>allowed.  If you really want the below program to work, one possibility
>would be to add the following constructor definitions to the class
>declaration of b:
>
>	 b() {};
>	 b(a) {};

	I propose that there should be a generic class declaration for a
method that returns the same type as the class which it is part of.

Example:

class A {
   me &func(...); // This function modifies a.
   // .
   // .
   // .  (More stuff)
};

class B : A {
   // .
   // .
   // .  (Even more junk)
};

main()
{
   B b;

   b = b.func();
}

	Of course calling it me isn't neccesarily a good idea, but there
still should be one.

(I believe this is what Mike Lijewski had in mind all along, but I'm not
sure.)

Have fun,
UUCP: rutgers!umn-cs!ux.acs.umn.edu!hopper   (Eric Hopper)
     __                    /)                       /**********************/
    / ')                  //                         * I went insane to   *
   /  / ______  ____  o  //  __.  __  o ____. . _    * preserve my sanity *
  (__/ / / / <_/ / <_<__//__(_/|_/ (_<_(_) (_/_/_)_  * for later.         *
Internet:              />                            * -- Ford Prefect    *
hopper@ux.acs.umn.edu </  #include <disclaimer.h>   /**********************/

schemers@vela.acs.oakland.edu (Roland Schemers III) writes:
|I understand your point of view though, and I think it would be nice
|if there was some construct in C++ to do what you want. I know some of
|my classes could use it. Maybe something like:
|
|class a { 
|  public: 
|    virtual& test() { 
|	// do some modification to the state of this object,
|	// then ...
|	return *this;
|	}
|};
|
|In otherwords, make the return type 'virtual' like functions. 

This is nice in that it uses an already key word.  However, this
would be too easily mixed up with people just forgetting to put
type names in their functions.  Rather than just

	virtual &method();

how about

	virtual class& method();

instead? "class" is already a keyword and it even sounds like what
it is -- a reference to the current "class".  But you're right,
this sounds like the syntax proposed for templates, so maybe they
will solve this problem without this changed syntax.

					Reid
--
Reid Ellis  264 Broadway Avenue, Toronto ON, M4P 1V9               Canada
rae@gpu.utcs.toronto.edu || rae%alias@csri.toronto.edu || +1 416 487 1383

Limsoon Wong writes:
>
>the program below is a contrived one.   it cannot  be compiled.
>the reason is a type fault. however, it exhibits a very central
>characteristic of update.    something should be  done to allow
>this kinds of programs.	   			    ---limsoon.
>
>
>
>#include <stream.h>
>class a { 
>  public: 
>    a& test() { 
>	// do some modification to the state of this object,
>	// then ...
>	return *this;
>};
>class b : public a { 
>  public:
>    int b;
>};
>main() { 
>  b B; 
>  B = B.test();
>  // type violation despite the fact that 
>  // `B' and `B.test()' are the same object.
>}


This is a not-infrequent idiom.  Another example of its use is
creating a "copy" method for collections (what's the return type?)
What one would like to write is

	class Collection {
	public:
		virtual ??? Copy();
	};

which will then be overridden in derived classes to do the 
appropriate copy operation.  Replacing the question marks with 
"Collection*" is not acceptable, for then clients would loose
static type information, as in


	class Collection {
	public:
		virtual Collection* Copy();
	};

	class Set : public Collection {
	public:
		virtual Collection* Copy();	// override for implementation
	}

	//...

	Set* pset, pset2 = ...;

	pset = pset2->Copy();	// illegal!


An approach to solving this problem involves using _non-virtual_ 
member functions.


	class Collection {
	protected:
		virtual Collection* _Copy();	// The real copy function
	public:
		Collection* Copy() { return _Copy(); }

	};

	class Set : public Collection {
		virtual Collection *_Copy();	// override implemenation
	public:
		Set* Copy() { return (Set *)_Copy(); }
	}

	//...

	Set* pset, pset2 = ...;

	pset = pset2->Copy();	// legal now


In the context of the example Limsoon presented, we would write:

	class a {
	protected:
		virtual void	_test()	{ /* do the real work here }
	public:
			a&	test()  { _test(); return *this; }
	};

	class b : public a {
	public:
			b&	test()  { _test(); return *this; }
	};

	main()
		{
		a A;
		b B;
		B = B.test();	// legal
		}


Yes, this is tedious for the class writer, but it makes client's job
a lot easier.  I personally agree, though, that it would be 
worthwhile investigating making the following constructions legal:

	class Collection {
	public:
		virtual	Collection *	Copy();
	};

	class Set : public Collection {
	public:
		virtual Set *		Copy();	   // illegal today
	};


At present, this gives an illegal virtual return type error.

The change to the existing rules is to allow overidings of virtual
functions to return a type to which a standard conversion may be
applied to obtain the inherited return type.  ("standard conversion"
may be too general; perhaps only derived-to-base standard conversions
should be applicable).  The appropriate member function signature would 
be chosen according to the static type of the pointer through which
it is invoked.


	Bob Atkinson
	Microsoft	

[Disclaimer: I am but one solitary opinionated C++ programmer]

In article <27634@netnews.upenn.edu>, limsoon@saul.cis.upenn.edu
(Limsoon Wong) writes:
|>
|>the program below is a contrived one.   it cannot  be compiled.
|>the reason is a type fault. however, it exhibits a very central
|>characteristic of update.    something should be  done to allow
|>this kinds of programs.	   			    ---limsoon.
|>
|>
|>
|>#include <stream.h>
|>class a { 
|>  public: 
|>    a& test() { 
|>	// do some modification to the state of this object,
|>	// then ...
|>	return *this;
|>};
|>class b : public a { 
|>  public:
|>    int b;
|>};
|>main() { 
|>  b B; 
|>  B = B.test();
|>  // type violation despite the fact that 
|>  // `B' and `B.test()' are the same object.
|>}
 
Your proposed program is not "type" correct. The method "test" returns
an object
of type a, not of type b. Objects of type a do not exhibit all of the
properties of type b, and therefore are not valid values for variables
of type b. The 
following version of main is type correct:

main() {
  b B;
  a A;
  A = B.test();
};

To accomplish what you were trying to do would require a second method on 
class b, also named test, that returns an object of type b. If the original
method on class a does, indeed, simply modify the referenced instance, then
the new method could be as simple as:

b::test() {
  a temp;
  temp = this.test();
  return *this;
};

As you have observed, strong typing does not give you everything for
free!                         
Paul C. Brown				brownpc@crd.ge.com
GE Corporate Research & Development
Schenectady, New York

>
>|In otherwords, make the return type 'virtual' like functions. 
>
>This is nice in that it uses an already key word.  However, this
>would be too easily mixed up with people just forgetting to put
>type names in their functions.
>

Yea, I realized the conflict with virtual functions after I sent the message.
Plus:
	virtual virtual&method();

Is quite ugly!!!!

>how about
>
>	virtual class& method();
>
>instead? "class" is already a keyword and it even sounds like what

wouldn't this cause problems with functions like:

	virtual class X& method();

Where X is a class name? I'm not sure if this is legal syntax, but it
seems to me you should be able to qualify the X with the class keyword.


>But you're right, this sounds like the syntax proposed for templates, 
> so maybe they will solve this problem without this changed syntax.
>

I hope templates solve this problem, if not, maybe a new keyword plus
some extra effort on the C++ translator/compiler is needed to solve this 
problem!

>					Reid
>
>Reid Ellis  264 Broadway Avenue, Toronto ON, M4P 1V9               Canada
>rae@gpu.utcs.toronto.edu || rae%alias@csri.toronto.edu || +1 416 487 1383

-- 
Roland J. Schemers III                              Systems Programmer 
schemers@vela.acs.oakland.edu (Ultrix)              Oakland University 
schemers@argo.acs.oakland.edu (VMS)                 Rochester, MI 48309-4401
"Get off your LEF and do something!"                (313)-370-4323

In article <27634@netnews.upenn.edu>, limsoon@saul.cis.upenn.edu
(Limsoon Wong) writes:

> the program below is a contrived one.   it cannot  be compiled.
> the reason is a type fault. however, it exhibits a very central
> characteristic of update.    something should be  done to allow
> this kinds of programs.	   			    ---limsoon.
> 
> 
> 
> #include <stream.h>
> class a { 
>   public: 
>     a& test() { 
> 	// do some modification to the state of this object,
> 	// then ...
> 	return *this;
> };
> class b : public a { 
>   public:
>     int b;
> };
> main() { 
>   b B; 
>   B = B.test();
>   // type violation despite the fact that 
>   // `B' and `B.test()' are the same object.
> }

This has surprising consequences in the face of virtuals, since the
caller thinks they are getting an instance of an A, not a B.  From a
static typechecking angle it works, and the parallel argument for
returning pointer to derived in place of pointer to base follows.

However, in the face of multiple inheritance this doesn't work at all.

Jon

My `Customization in C++' paper in the '90 Usenix C++ Proceedings
discusses a reasonably clean, but extensive proposal that would
support the desired usage:

#include <stream.h>
class a { 
  public: 
    template a& test() {  // *** Note the qualifier ***
	// do some modification to the state of this object,
	// then ...
	return *this;
};

class b : public a { 
  public:
    int b;
};

main() { 
  b B; 
  B = B.test(); // *** Legal under customization ***
  // type violation despite the fact that 
  // `B' and `B.test()' are the same object.
}


While I played down the expressivity aspects of the type qualifier
sense of `template' and concentrated on optimization consequences,
the proposed constructs are indeed extremely valuable for writing
container classes and the like.

I'd love to hear from anyone concerning the standardizability of
the proposal. 

-Doug
--
Doug Lea, Computer Science Dept., SUNY Oswego, Oswego, NY, 13126 (315)341-2688
email: dl@g.oswego.edu            or dl@cat.syr.edu
UUCP :...cornell!devvax!oswego!dl or ...rutgers!sunybcs!oswego!dl