A suggestion: That one is allowed to write "virtual n", where n = 0, 1,
... indicates which argument to polymorphy overload.

For example
  class A {
    virtual T f(B) const;
  };
and
  class A {
    virtual 0 T f(const A&, B);
  };
would be equivalent. Syntactically the latter should be called as
  T f(const A&, B);
though.

Then
  class B {
    virtual 1 T g(A, const B&);
  };
would produce a function that syntactically is used as
  T g(A, const B&);

One could also think of the variation where
  class B {
    virtual 1 T g(A) const;
  };
produces the function that syntactically is used as
  T g(A, const B&);
The variation above with the explicit polymohy argument makes the keyword
"this" unnecessary, though.

The compiler would merely have to rearrange the order of the arguments,
putting the polymorphy argument first, so that one can rely on the same
kind of implementation as before.

The cases that gave me this idea are the operators >> and << in connection
with IO streams: Then it becomes cumbersome to always having to declare
these operators externally as friends, while if polymorphy is to be used,
one has to invent new names for the local IO operators. It would simplify
if one could merely write
  class A {
  public:
    virtual 1 ostream& operator<<(ostream&, const A&);
  };
and that would be it: operator<< can be used both for direct output and
for polymorphy output.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Hans Aberg" <remove.haberg@matematik.su.se> schrieb im Newsbeitrag
news:remove.haberg-0107011429340001@du139-226.ppp.su-anst.tninet.se...
> A suggestion: That one is allowed to write "virtual n", where n = 0, 1,
> ... indicates which argument to polymorphy overload.
>
> For example
>   class A {
>     virtual T f(B) const;
>   };
> and
>   class A {
>     virtual 0 T f(const A&, B);
>   };
> would be equivalent. Syntactically the latter should be called as
>   T f(const A&, B);
> though.
>
> Then
>   class B {
>     virtual 1 T g(A, const B&);
>   };
> would produce a function that syntactically is used as
>   T g(A, const B&);
>
> One could also think of the variation where
>   class B {
>     virtual 1 T g(A) const;
>   };
> produces the function that syntactically is used as
>   T g(A, const B&);
> The variation above with the explicit polymohy argument makes the keyword
> "this" unnecessary, though.
>
> The compiler would merely have to rearrange the order of the arguments,
> putting the polymorphy argument first, so that one can rely on the same
> kind of implementation as before.
>
> The cases that gave me this idea are the operators >> and << in connection
> with IO streams: Then it becomes cumbersome to always having to declare
> these operators externally as friends, while if polymorphy is to be used,
> one has to invent new names for the local IO operators. It would simplify
> if one could merely write
>   class A {
>   public:
>     virtual 1 ostream& operator<<(ostream&, const A&);
>   };
> and that would be it: operator<< can be used both for direct output and
> for polymorphy output.
>
would it not be more convincing to qualify the parameter directly with the
virtual keyword like:
    ostream& operator<<(virtual ostream&,const A&)
?
And would it not be much nicer if we had multimethods (see
http://www.op59.net/cmm/cmm-0.10/users.html for an implementation as language
extension to c++)?


--
Arne


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <9hqi7q$spv$07$1@news.t-online.com>, "Arne Adams"
<Arne.Adams@bigfoot.com> wrote:
>would it not be more convincing to qualify the parameter directly with the
>virtual keyword like:
>    ostream& operator<<(virtual ostream&,const A&)

Perhaps. In your example it would read as
  class A {
  public:
    ostream& operator<<(ostream&, virtual const A&);
  };
I think.

>And would it not be much nicer if we had multimethods (see
>http://www.op59.net/cmm/cmm-0.10/users.html for an implementation as language
>extension to c++)?

In BS's DEC++, sec 13.8 the author indicates  why he did not add
multimethods: Basically, it becomes complicated to find a good
implementation when the types multiply. He also analyzes the problem in
the context of using double dispatch.

Now, I have used double dispatch in a polymorphic hierarchy, but then
there is in effect only one type in use, the polymorphy variable.
Basically, the workaround I have found for the problems that BS indicates
is to only use one type, a polymorphic one.

So I guess that unless somebody comes up with a good solution to those
indicated problems, multimethods will not be added to C++. (But this is
just my own personal guess.)

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Hans Aberg" <remove.haberg@matematik.su.se> schrieb im Newsbeitrag
news:remove.haberg-0307011233310001@du131-226.ppp.su-anst.tninet.se...
> In article <9hqi7q$spv$07$1@news.t-online.com>, "Arne Adams"
> <Arne.Adams@bigfoot.com> wrote:
> >would it not be more convincing to qualify the parameter directly with the
> >virtual keyword like:
> >    ostream& operator<<(virtual ostream&,const A&)
>
> Perhaps. In your example it would read as
>   class A {
>   public:
>     ostream& operator<<(ostream&, virtual const A&);
>   };
> I think.
If I could have this freestanding ostream& operator<<(ostream&, virtual const
A&); and not as a member of a class, then I could live with the restriction
having only one virtual parameter.
The interface defined by classes is closed. Purely object oriented designs tend
to degrade to "Designs" like:
class WithAllFunctionsICurrentlyNeed {...}

class OooopsButIAlsoNeedThese:public WithAllFunctionsICurrentlyNeed
{...}

class ButINeedToSuppressThose:public OooopsButIAlsoNeedThese
{..}
// can be go on like this unboundedly
Which in turn almost inevitably leeds somewhere else in the code to statements
like:

if (realObject = dynamic_cast<ButINeedToSuppressThose*>(whatsThisReally))
    realObject->suppressedFunctionWhichRequiresOneParameterHere(aParameter);
else
if (realObject = dynamic_cast<OooopsButIAlsoNeedThese*>(whatsThisReally))
    realObject->addedFunction();
else
if (realObject = dynamic_cast<WithAllFunctionsICurrentlyNeed*>(whatsThisReally))
    realObject->baseFunction();



--
Arne


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Hans Aberg" <remove.haberg@matematik.su.se> wrote in message
news:remove.haberg-0307011233310001@du131-226.ppp.su-anst.tninet.se...
> In article <9hqi7q$spv$07$1@news.t-online.com>, "Arne Adams"
> <Arne.Adams@bigfoot.com> wrote:

> >And would it not be much nicer if we had multimethods (see
> >http://www.op59.net/cmm/cmm-0.10/users.html for an implementation as
language
> >extension to c++)?
>
> In BS's DEC++, sec 13.8 the author indicates  why he did not add
> multimethods: Basically, it becomes complicated to find a good
> implementation when the types multiply. He also analyzes the problem in
> the context of using double dispatch.
>
> Now, I have used double dispatch in a polymorphic hierarchy, but then
> there is in effect only one type in use, the polymorphy variable.
> Basically, the workaround I have found for the problems that BS indicates
> is to only use one type, a polymorphic one.
>
> So I guess that unless somebody comes up with a good solution to those
> indicated problems, multimethods will not be added to C++. (But this is
> just my own personal guess.)

Here's what I think are the three main issues, and how Cmm addresses them:


1. multimethods should be as efficient in time and space as possible.

It's straightforward to get LogN dispatch time where N is the number of
combinations of dynamic types that are ever used,  but dispatch with more
than 1 virtual parameter will always be a lot slower (e.g. 10 times slower)
than a virtual function call. Cmm supports the use of custom container types
so that the user can (for example) write their own map replacement to lookup
function pointers from a set of std::type_info*-s. There's an example in cmm
0.10 that caches the last lookup for example. A t the moment, Cmm's dispatch
code is duplicated for each virtual function, so its space efficiency could
be improved.


2. Multimethods need to be easy to use. And that means that the syntax has
to be simple. This is why I don't like the various template-driven
multimethod implementations. Apart from their workings making my head hurt,
they have a terribly messy syntax.

Cmm's syntax (based on the one suggested in D&EC++) is, I think, pretty
intuitive.


3. Do we actually need multimethods? If they are only useful occasionally,
then verbose equivalents such as the Visitor Pattern or the various template
techniques described by Meyers / Alexandrescu and others are probably
sufficient. As ever, this point is made in the D&EC++.

I've gone to the trouble of writing Cmm because I suspect that there are
many uses of multimethods that have gone unnoticed because languages don't
support them. It's a bit like saying `if all you have is a hammer,
everything looks like a nail' except in this case it's `if you don't have a
hammer, even nails don't look like nails'. In an ACCU Overload article, I
mentioned two examples - GUI event dispatching and error-message
generation - that I think really require multimethod support to solve
elegantly.


- Julian
--
http://www.op59.net/









---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <9humgi$7gq$06$1@news.t-online.com>, "Arne Adams"
<Arne.Adams@bigfoot.com> wrote:
>>In your example it would read as
>>   class A {
>>   public:
>>     ostream& operator<<(ostream&, virtual const A&);
>>   };
>> I think.
>If I could have this freestanding ostream& operator<<(ostream&, virtual const
>A&); and not as a member of a class, then I could live with the restriction
>having only one virtual parameter.

I figure the current restriction of virtual functions always within the
class body is due to the typical implementations of a virtual functions
table with offsets.

If one has a Java style type implementation (resolving the "fragile base
class problem") using instead lookup names and offset numbers computed at
runtime, then one could have virtual functions without the class body.

But I do not know what is considered here in terms of additions to C++.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]