|
|
Re: Bolt-Ins for Contract and Extension Classes
|
Posted: Apr 28, 2005 2:53 PM
|
|
> > > So I would strongly favour implementing those methods
> > as
> > > non member functions.
> >
> > Why?
>
> Because they (the String_ext methods) dont need to
> be members.
>
> They only operate on the public String interface, they
> dont need access to the protected parts of String_Impl.
> They dont override any of String_Impl's members, they are
> just extensions.
> They dont have any state of their own. So dont need to be
> in a class at all.
Of course they don't need to be. No member function ever has to be defined.
> Making those algorithms members of a class and making that
> class derived from String only adds dependencies and
> increases coupling.
Increasing coupling and adding dependencies is not neccessarily a bad thing, especially when it makes logical sense.
> > I don't see how using non-members is a superior
> approach
> > over extension classes. Nothing is saved by making the
> > function non-member functions, they are just scattered
> > throughout the namespace in a non-modular manner. It
> feels
> > like I am stepping back in time to old fashioned C ;-)
>
> Nothing has to be 'scattered', thats a bit of a loaded
> term. They can be grouped together in sub namespaces if
> you like.
Okay.
> And you could be stepping sideways into the
> parallel universe of functional programming :-P
I wouldn't agree that functional programming is a parallel universe.
> > > There are a couple of other advantages to non
> members.
> > If
> > > someone has got a 'raw' String_Impl class or another
> > class
> > > statisfying the String interface, they cant use the
> > > methods of String_ext without creating a new
> String_ext
> > > fom the String_Impl. Doesnt this defeat the dynamic
> > typing
> > > goals that you have been working towards?
> >
> > Not really, I don't view dynamic and static typing as
> > mutually exclusive goals.
>
> I agree about dynamic and static typing. Thats why I was
> so interested in your 'Proposed Boost' Interfaces Library.
> And that is also why I've got a strong dislike of this
> String_ext class.
>
> Say I've got a class, YetAnotherString, which I'm using in
> lots of places. Say YetAnotherString statisfies your
> String interface. But I dont have a rich library of string
> algorithms like Concat(). If Concat was a nonmember
> function, I could just do this:-
>
> YetAnotherString foo(YetAnotherString fred,
> YetAnotherString bob) {
> OOTL::Concat(fred, bob);
> return fred;
> }
>
> And it would just work.
Well it would work if Concat was a template function.
template<typename String_T>
void Concat(String_T& x, const String& y)
{
// ...
}
Which I really don't like.
> With the String_ext approach I have to do this:
>
>
> YetAnotherString foo(YetAnotherString& fred,
> YetAnotherString& bob) {
> typedef OOTL::String_ext<YetAnotherString> YourString;
> YourString fred2(fred); //string is copied
> YourString bob2(bob); //string is copied
> fred2.Concat(bob2);
> return (YetAnotherString)fred2;
> }
>
Why would you not use YourString throughout?
typedef OOTL::String_ext<YetAnotherString> YourString;
YourString foo(YourString& fred, YourString& bob) {
return fred.Concat(bob);
}
> In fact I just wouldnt use it. By making these member
> functions you've massively limited the utility of your
> library.
I think that is a significant overstatement. The same could be said of any kind of information hiding. Some kind of restriction is desirable.
> Moral of the story. Dont use inheritance unless you need
> to, and I've given a checklist of when you might need to
> at the top of my post.
I strongly disagree.
|
|
Previous Topic
