Topic: Implicit Interfaces
Author: rdnewsNOSPAM2006@sbcglobal.net ("Tony")
Date: Tue, 26 Dec 2006 18:47:09 GMT Raw View
class Interface
{
public:
virtual void DoItNow()=0;
};
class A: public Interface
{
public:
void DoItNow(); // satisfies interface explicitly
};
class B
{
public:
void DoItNow(); // could satisfy interface implicitly
};
// Must wrap B to get a class to behave like Interface :(
//
class C: public Interface
{
B rep;
public:
void DoItNow(){ rep.DoItNow(); }
};
void some_func(Interface* obj)
{
obj->DoItNow();
}
void another_func()
{
A a; // IS explicitly an Interface
B b; // is NOT an explicit Interface
C c; // wraps a B to use it as an Interface
some_func(&a); // obviously OK
some_func(&b); // error! b is not derived from Interface
some_func(&c); // obviously OK
}
If the second call worked via implicit interfaces, the
wrapper class C could be eliminated. Am I describing
dynamic typing? Are Implicit Interfaces what template-
only "concepts" (proposed) are hinting at? I don't think
it's dynamic typing, becuase I'd want to know at compile
time whether an object satisfies an interface or not.
Templates consider type while interfaces consider behavior.
Do Implicit Interfaces add "the other half" of what's missing
to templates? Replace them?
Just thinking out loud above and below...
class Drawable
{
virtual void Draw()=0;
};
class Window
{
void Draw();
};
class Graphic
{
void Draw();
};
class BillyTheKid
{
void Draw();
};
Window, Graphic, BillyTheKid are all Drawables implicitly.
A Graphic is not a Window though because Window is not an
interface class (pure ABC). Sure, you'll get weird results if
you pass a BillyTheKid to a Canvas object, but is the concept
of Implicit Interfaces still something to be pursued?
Hmmm.... I'm talking about "aspects" kinda? Do we need all
these mechanisms: templates, template concepts, aspects,
dynamic typing, implicit interfaces... others? I guess I'm
wondering in a remote way if impicit interfaces solve or could
solve a lot of the problems the other ones do.
Well that's enough brainstorming for Xmas night (!).
Tony
---
[ 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.comeaucomputing.com/csc/faq.html ]
Author: "perrog@gmail.com" <perrog@gmail.com>
Date: Wed, 27 Dec 2006 12:33:33 CST Raw View
I'm not sure what you mean by "implicit interfaces"? A new
compiler phase that generates a bunch of related member functions
automatically? Or that a set of class members (member functions, types
and constants) conforms to a common "protocol" (implemented in
terms of a C++0x concept)?
For the latter case, there are tree related activities in C++0x core
language
Concepts (2003/n1510.pdf, 2006/n2042.pdf)
Auxiliary classes (2004/n1742.pdf, 2004/n1585.pdf)
Plug-in in C++ (2006/2015.pdf)
Just append the document ID to the end of the following URL
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/
to read the proposals.
"Tony" skrev:
> class Interface
> {
> public:
> virtual void DoItNow()=0;
> };
>
> class A: public Interface
> {
> public:
> void DoItNow(); // satisfies interface explicitly
> };
>
> class B
> {
> public:
> void DoItNow(); // could satisfy interface implicitly
> };
>
> // Must wrap B to get a class to behave like Interface :(
> //
> class C: public Interface
> {
> B rep;
> public:
> void DoItNow(){ rep.DoItNow(); }
> };
>
> void some_func(Interface* obj)
> {
> obj->DoItNow();
> }
>
> void another_func()
> {
> A a; // IS explicitly an Interface
> B b; // is NOT an explicit Interface
> C c; // wraps a B to use it as an Interface
> some_func(&a); // obviously OK
> some_func(&b); // error! b is not derived from Interface
> some_func(&c); // obviously OK
> }
I would say, that class A "is an introverted" representation of
class Interface. Class C "is an extroverted" representation of
class Interface since it make class B is-a Interface. Up to date, only
"is-a-introverted" relationships are considered as the real things,
all others just hoaxes.
> class Drawable
> {
> virtual void Draw()=0;
> };
>
> class Window
> {
> void Draw();
> };
>
> class Graphic
> {
> void Draw();
> };
>
> class BillyTheKid
> {
> void Draw();
> };
>
You can already achieve this in C++, just with slightly different
syntax. Create a dispatch table containing pointer to member functions
and pass that to the function as a generic type pointer, and bypass the
inheritance limitation and type checking.
Some would consider this to induce undefined behaviours, but let's
just say that without multiple inheritance, all pointers conversion
from Window, Graphic, BillyTheKid to Drawable becomes trivial and
conforms to the Convertible-concept.
auto concept DoItNowConcept<typename T> {
void DoItNow(T&); // void T::DoItNow();
};
struct Interface {
Drawable *this_;
typedef void (Drawable::*DrawFunc)();
void (Drawable::*draw_)();
template<typename T>
where Convertible<T*,Drawable*> //pseudo-code[lib.convertible]
where DoItNowConcept<T> // pseudo-code
Interface(T &obj)
: this_((Drawable *)&obj)
, draw_((DrawFunc) &T::Draw)
{ }
inline void Draw() {
(this_->*draw_)();
}
};
Tony skrev:
> Hmmm.... I'm talking about "aspects" kinda? Do we need all
> these mechanisms: templates, template concepts, aspects,
> dynamic typing, implicit interfaces... others?
Just assume "delegates" was on that to the list, too. It would
represent a more efficient representation of pointer to member
functions (plural) than the dispatch-table above. It would be more
logical to have delegates; it also become more memory efficient and
gain performance benefits. Because not all scenarios need a runtime
dispatch-table like above. A delegate would be a pointer (or reference)
to a c++0x concept.
---
[ 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.comeaucomputing.com/csc/faq.html ]
Author: rdnewsNOSPAM2006@sbcglobal.net ("Tony")
Date: Thu, 28 Dec 2006 17:35:57 GMT Raw View
<perrog@gmail.com> wrote in message=20
news:1167228759.020052.90640@f1g2000cwa.googlegroups.com...
> I'm not sure what you mean by "implicit interfaces"?
The compiler recognizing that a class satisfies an interface
(pure ABC) requirement.
> A new
> compiler phase that generates a bunch of related member functions
> automatically?
No.
> Or that a set of class members (member functions, types
> and constants) conforms to a common "protocol" (implemented in
> terms of a C++0x concept)?
Just the public methods of the pure ABC.
> For the latter case, there are tree related activities in C++0x core
> language
> =B7 Concepts (2003/n1510.pdf, 2006/n2042.pdf)
I mentioned that one.
> =B7 Auxiliary classes (2004/n1742.pdf, 2004/n1585.pdf)
I haven't heard of those yet.
> =B7 Plug-in in C++ (2006/2015.pdf)
Sounds relevant.
> Just append the document ID to the end of the following URL
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/
> to read the proposals.
I will (tomorrow). Thanks.
>
> "Tony" skrev:
>
>> class Interface
>> {
>> public:
>> virtual void DoItNow()=3D0;
>> };
>>
>> class A: public Interface
>> {
>> public:
>> void DoItNow(); // satisfies interface explicitly
>> };
>>
>> class B
>> {
>> public:
>> void DoItNow(); // could satisfy interface implicitly
>> };
>>
>> // Must wrap B to get a class to behave like Interface :(
>> //
>> class C: public Interface
>> {
>> B rep;
>> public:
>> void DoItNow(){ rep.DoItNow(); }
>> };
>>
>> void some_func(Interface* obj)
>> {
>> obj->DoItNow();
>> }
>>
>> void another_func()
>> {
>> A a; // IS explicitly an Interface
>> B b; // is NOT an explicit Interface
>> C c; // wraps a B to use it as an Interface
>> some_func(&a); // obviously OK
>> some_func(&b); // error! b is not derived from Interface
>> some_func(&c); // obviously OK
>> }
>
> I would say, that class A "is an introverted" representation of
> class Interface. Class C "is an extroverted" representation of
> class Interface since it make class B is-a Interface. Up to date, only
> "is-a-introverted" relationships are considered as the real things,
> all others just hoaxes.
Class B is the one currently under the looking glass.
(I'll look at the rest of your post tomorrow).
Tony=20
---
[ 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.comeaucomputing.com/csc/faq.html ]
Author: "Tony" <rdnewsNOSPAM2006@sbcglobal.net>
Date: Fri, 29 Dec 2006 12:15:02 CST Raw View
<perrog@gmail.com> wrote in message
news:1167228759.020052.90640@f1g2000cwa.googlegroups.com...
> I'm not sure what you mean by "implicit interfaces"? A new
> compiler phase that generates a bunch of related member functions
> automatically? Or that a set of class members (member functions, types
> and constants) conforms to a common "protocol" (implemented in
> terms of a C++0x concept)?
>
> For the latter case, there are tree related activities in C++0x core
> language
> Concepts (2003/n1510.pdf, 2006/n2042.pdf)
I've already read some stuff (very briefly as always) on "template
concepts", and basically, well yawn, but you probably already
know that I have an avoidance of template machinery and the
tricks and the evolution of it. But that's just a feeling, not a
scientific observation.
So, are we all caught up? Well no. FG might want to entertain
my request to briefly sum up his paper in layman's terms. No
problem if he's too busy for that. And also, anyone is free to
bore me to death with "plug ins" and "ABI" talk when I am
"in love with" interfaces (oh, go on, give it a try!).
Tony
---
[ 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.comeaucomputing.com/csc/faq.html ]
Author: "perrog@gmail.com" <perrog@gmail.com>
Date: Fri, 29 Dec 2006 12:29:32 CST Raw View
"Tony" skrev:
> >> class Interface
> >> {
> >> public:
> >> virtual void DoItNow()=0;
> >> };
> >>
> >> class A: public Interface
> >> {
> >> public:
> >> void DoItNow(); // satisfies interface explicitly
> >> };
> >>
> >> class B
> >> {
> >> public:
> >> void DoItNow(); // could satisfy interface implicitly
> >> };
> >>
> >> // Must wrap B to get a class to behave like Interface :(
> >> //
> >> class C: public Interface
> >> {
> >> B rep;
> >> public:
> >> void DoItNow(){ rep.DoItNow(); }
> >> };
> >>
> >> void some_func(Interface* obj)
> >> {
> >> obj->DoItNow();
> >> }
> >>
> >> void another_func()
> >> {
> >> A a; // IS explicitly an Interface
> >> B b; // is NOT an explicit Interface
> >> C c; // wraps a B to use it as an Interface
> >> some_func(&a); // obviously OK
> >> some_func(&b); // error! b is not derived from Interface
> >> some_func(&c); // obviously OK
> >> }
> >
> > I would say, that class A "is an introverted" representation of
> > class Interface. Class C "is an extroverted" representation of
> > class Interface since it make class B is-a Interface. Up to date, only
> > "is-a-introverted" relationships are considered as the real things,
> > all others just hoaxes.
>
> Class B is the one currently under the looking glass.
>
> (I'll look at the rest of your post tomorrow).
The extroversion is some kind of "strategy design pattern" in Eric
Gamma terminology.
---
[ 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.comeaucomputing.com/csc/faq.html ]
Author: "Tony" <rdnewsNOSPAM2006@sbcglobal.net>
Date: Fri, 29 Dec 2006 12:29:57 CST Raw View
<perrog@gmail.com> wrote in message
news:1167228759.020052.90640@f1g2000cwa.googlegroups.com...
> I'm not sure what you mean by "implicit interfaces"? A new
> compiler phase that generates a bunch of related member functions
> automatically? Or that a set of class members (member functions, types
> and constants) conforms to a common "protocol" (implemented in
> terms of a C++0x concept)?
>
> For the latter case, there are tree related activities in C++0x core
> language
> Concepts (2003/n1510.pdf, 2006/n2042.pdf)
> Auxiliary classes (2004/n1742.pdf, 2004/n1585.pdf)
> Plug-in in C++ (2006/2015.pdf)
Just read that one. It's not only "the low hanging fruit", but also
kinda dated. I was doing that kind of stuff 10 years ago and now
the paper is suggesting standardizing it? Well guess what? Times
have changed: DLLs and the associated hell are under scrutiny.
The paper doesn't get to the crux of a solution because it is stuck
in the muck of generality (OK, that's a bit too strong, but you get
my drift). It doesn't address the current thoughts on interfaces and
the "also rans" (hehe ;) ). I tell ya, Implicit Interfaces have a
future. :)
OK, I'm going off to read the other papers now. I like reading
short and to the point stuff, but the plug in paper was just a
"filing for permit" kind of thing IMO. Yeah sure, standardize
that stuff if you want. But it's just so conceptually easy to do
every time all the time that I find the paper borish and
unenlightening, well because it's exactly that! Not that it
the low hanging fruit stuff doesn't need to be standardized.
Hmmm... or does it? Actually, it probably doesn't. The
real trick is getting the platforms to standardize before
they reach the consumer. Yeah, that's it: <first one to
email me what I was thinking belonged after the ':' gets...
my respect for being an intellectual and great thinker>.
(I better write down what I was thinking in case someone
actually figures it out! OK, I wrote it down. I'll reveal only
under non-disclosure agreement or lots of money. :) Hehe.)
Tony
---
[ 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.comeaucomputing.com/csc/faq.html ]
Author: rdnewsNOSPAM2006@sbcglobal.net ("Tony")
Date: Fri, 29 Dec 2006 18:30:44 GMT Raw View
<perrog@gmail.com> wrote in message=20
news:1167228759.020052.90640@f1g2000cwa.googlegroups.com...
> I'm not sure what you mean by "implicit interfaces"? A new
> compiler phase that generates a bunch of related member functions
> automatically? Or that a set of class members (member functions, types
> and constants) conforms to a common "protocol" (implemented in
> terms of a C++0x concept)?
>
> For the latter case, there are tree related activities in C++0x core
> language
[...]
> =B7 Auxiliary classes (2004/n1742.pdf, 2004/n1585.pdf)
OK, I'm leaving 1742 for later. It started out saying it was going
to address specific problems, but then listed solutions. I think I'd
rather have someone's review of the major points in that paper
rather than struggling through it (I didn't get past the first page).
(Aside: I did notice who wrote that paper and sometimes, where
I wouldn't look at a USENET post, I _would_ if he was the poster
because I've somehow gotten the impression that he is one of the
definitive experts on the subject. So the paper is probably very
relevent but just beyond me (and my ADS, LOL). Got into the
details too quick or something. If someone could summarize it
in English, that would be good.)
Tony=20
---
[ 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.comeaucomputing.com/csc/faq.html ]
Author: rdnewsNOSPAM2006@sbcglobal.net ("Tony")
Date: Fri, 29 Dec 2006 18:33:19 GMT Raw View
<perrog@gmail.com> wrote in message=20
news:1167228759.020052.90640@f1g2000cwa.googlegroups.com...
> I'm not sure what you mean by "implicit interfaces"? A new
> compiler phase that generates a bunch of related member functions
> automatically? Or that a set of class members (member functions, types
> and constants) conforms to a common "protocol" (implemented in
> terms of a C++0x concept)?
>
> For the latter case, there are tree related activities in C++0x core
> language
[...]
> =B7 Auxiliary classes (2004/n1742.pdf, 2004/n1585.pdf)
OK. I'm reading 1585 now. After the first paragraph, I'm thinking,
that I solved that problem already: when I have stand alone functions,
I preface them with 'c_'. Lately, I've been considering 'n_' for inlines
but that has maintenance implications when an inline becomes a
full fledged function at a later time.
my_container.Swap(yada);
c_Swap(yada);
Perfectly clear to me what's going on!
After the 3rd paragraph I'm thinking: "and that pesky C-linkage as the
lowest common denominator is a bitch sometimes!".
Example: exploding return values to ensure return values are checked.
Nice, _BUT_, can't do it with the lowest common denominator C-linkage
function. Read, "non-exportable". (To the uninitiated: you can't return a
C++ class object from a function declared "extern C", but "extern C" is
exactly what you want to use DLLs).
OK, perhaps I don't need to read the rest of the paper and FG would
chime in here and be the "movie spoiler" (?) (please?).
Tony
---
[ 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.comeaucomputing.com/csc/faq.html ]