sirwillard@my-deja.com wrote:
>
> In article <384797BC.3071857F@arexsys.com>,
>   t.grellier@arexsys.com wrote:
> > Hello,
> >
> > STL template library relies on an interface notion that is external to
> > the language.
>
> No, it relies on genericity.  Genericity will work only when the
> replacement type follows certain interface rules, but this is not quite
> the same thing as a full blown interface definition within a language.

Yes, but my purpose it to help visualizing these interface rules within
code. So I was thinking of using an interface or package notion. Maybe I
shall have used package rather than interface term. Because I can hardly
conceptually distinguish them : they are here to express views of
objects. What are high level language all about ? Just making the
concepts and analysis more visible outside of implementation noise.

>
> > Pattern Design relies on interface notion which is made internal to
> > language.
>
> I don't agree with this either.  Patterns are simply reusable "methods"
> for constructing complex programming idioms.  It's quite possible to
> use a Pattern without using an interface concept.

Of course. But that's a bit equivalent to say it's possible to do object
programming with a non object programing language. So here I'm not
saying that C++ shall become a pattern language. I'm just saying that
packages can make more visible the underlying usage of a pattern. This
may not be adapted to all patterns though.

>
> > So why not introducing interface notion to C++ ?
>
> Because we already have it?  An interface is nothing more than a class
> who's methods are all abstract.

And where inheritence is virtual.
But using inheritence has a runtime cost : data type layout is modified.

>
> > For now one can rely on either multiple inheritence or preprocessor to
> > made them explicit.
>
> Using the preprocessor is a Bad Idea (TM).  It's use should be avoided
> when ever an alternative is available.

Yes using preprocessor is a bad idea, but here the alternative is
comments or hard to maintain external documentation which rather than
decreasing implementation noise reinforce it. This usage of preprocessor
can increase reuse. The usage of a package can properly do it.

>
> This is NOT what one normally thinks of as an interface.  Typical
> interface useage requires the ability to use the object type
> polymorphically.  In other words, I should be able to use C any where
> that a SingletonInterface pointer/reference could be used.

Well I shall definitively have used the package term. To me, the
polymorphism is the runtime side of genericity, or the genericity is the
compile time side of the polymorphism.

> However, this is really
> only a benefit in solidifying the requirements and in diagnosing
> programming errors.

That's not an ONLY for me because this is the aiming of high level
languages. The other benefit is that it may help reducing code to write
(only for prototyping I admit, but this is already a significant part of
the C++ coding effort).

> Whether or not you can specify the interface
> requirements for a generic within the language is, for the most part,
> irrelevant, since specified or not, if a type doesn't meet the
> requirements it won't compile.

No, it may compile when a subset of interface requirement is used. Well
this behaviour may be preserved even with a package notion.


Thierry
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <384797BC.3071857F@arexsys.com>,
  t.grellier@arexsys.com wrote:
> Hello,
>
> STL template library relies on an interface notion that is external to
> the language.

No, it relies on genericity.  Genericity will work only when the
replacement type follows certain interface rules, but this is not quite
the same thing as a full blown interface definition within a language.

> Pattern Design relies on interface notion which is made internal to
> language.

I don't agree with this either.  Patterns are simply reusable "methods"
for constructing complex programming idioms.  It's quite possible to
use a Pattern without using an interface concept.

> So why not introducing interface notion to C++ ?

Because we already have it?  An interface is nothing more than a class
who's methods are all abstract.

> For now one can rely on either multiple inheritence or preprocessor to
> made them explicit.

Using the preprocessor is a Bad Idea (TM).  It's use should be avoided
when ever an alternative is available.

> For example:
>
> 1/ Pattern Design
>
> #define SINGLETON_INTERFACE(T)\
> public:                       \
>   T* instance();              \
> protected:                    \
>   T();                        \
> private:                      \
>   T(const T&) {}              \
>   T& operator=(const T&) {}
>
> class C {
>   SINGLETON_INTERFACE(C);
> };

This is NOT what one normally thinks of as an interface.  Typical
interface useage requires the ability to use the object type
polymorphically.  In other words, I should be able to use C any where
that a SingletonInterface pointer/reference could be used.

> 2/ STL type constraint
>
> #define ASSIGNABLE(T)                \
> public:                              \
>   T(const T&);                       \
>   T& operator=(const T&);            \
>   void swap(const T&);
>
> class C {
>   ASSIGNABLE(C);
> };
>
> template <class T> // ASSIGNABLE(T)
> class TC {
>  ...
> };
>
> In both cases verbosity is reduced, but on may not combine interfaces
> using the same operators. And the interface constraint can not be
> integrated in template definition to benefit from language checks (abit
> like Eiffel was proposing).

Eiffel didn't propose this, they used it ;).  However, this is really
only a benefit in solidifying the requirements and in diagnosing
programming errors.  Whether or not you can specify the interface
requirements for a generic within the language is, for the most part,
irrelevant, since specified or not, if a type doesn't meet the
requirements it won't compile.

> So introducing interfaces as a compile time notion just on purpose to
> increase readibility of code and reduce verbosity can be an improvment
> against totally external language notion that can only be partially
made
> internal with preprocessor macros.

Again, don't use macros.

> This has not Java semantic which accepts interfaces as argument of
> methods or operators, but is more a syntactical facility relying on a
> similar mechanism as templates. And interfaces are not aiming as being
> runtime reflective.
>
> Hence on may use notations such as :
>
> interface Assignable<T> {
>    ...
> };
>
> interface Singleton<T> {
> };
>
> template <interface Assignable<T> > class TC { ... };
>
> class C {
>   Assignable<C>;
>   Singleton<C>;
> };
>
> where compiler can raise an error because two operators are redefined
> with different accessibility tags.

You've defined nothing here.  All you've done is prototype.  You still
have to define every single method of each "interface" (note that I put
this in quotes because you're using a concept foreign to that typically
thought of as an interface in most languages).  This, to me at least,
means you've failed to reduce verbosity.  So the most that you've
gained by this is a slightly better diagnostic produced at compile time
when a programming error occurs.  This isn't worth it, IMHO.

> What do you think of introducing packages in C++ ?

Packages are not really appropriate to C++, and honestly would be near
impossible to do.  Header files and namespaces will provide most of
what you need here.


Sent via Deja.com http://www.deja.com/
Before you buy.


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hello,

STL template library relies on an interface notion that is external to
the language.
Pattern Design relies on interface notion which is made internal to
language.

So why not introducing interface notion to C++ ?

For now one can rely on either multiple inheritence or preprocessor to
made them explicit.

For example:

1/ Pattern Design

#define SINGLETON_INTERFACE(T)\
public:                       \
  T* instance();              \
protected:                    \
  T();                        \
private:                      \
  T(const T&) {}              \
  T& operator=(const T&) {}

class C {
  SINGLETON_INTERFACE(C);
};

2/ STL type constraint

#define ASSIGNABLE(T)                \
public:                              \
  T(const T&);                       \
  T& operator=(const T&);            \
  void swap(const T&);

class C {
  ASSIGNABLE(C);
};

template <class T> // ASSIGNABLE(T)
class TC {
 ...
};

In both cases verbosity is reduced, but on may not combine interfaces
using the same operators. And the interface constraint can not be
integrated in template definition to benefit from language checks (abit
like Eiffel was proposing).

So introducing interfaces as a compile time notion just on purpose to
increase readibility of code and reduce verbosity can be an improvment
against totally external language notion that can only be partially made
internal with preprocessor macros.

This has not Java semantic which accepts interfaces as argument of
methods or operators, but is more a syntactical facility relying on a
similar mechanism as templates. And interfaces are not aiming as being
runtime reflective.

Hence on may use notations such as :

interface Assignable<T> {
   ...
};

interface Singleton<T> {
};

template <interface Assignable<T> > class TC { ... };

class C {
  Assignable<C>;
  Singleton<C>;
};

where compiler can raise an error because two operators are redefined
with different accessibility tags.


What do you think of introducing packages in C++ ?

Thierry
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]