"Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:akd51e$1hvo$1@digitaldaemon.com...
> But do we want that extra indirection, after all?
> In practice you usually need class templates.
> You will end up typedef-ing everything, to avoid the burden of the
> unnecessary indirection.
>
> typedef   RedBlackTree  instance RBT_Template(char).TheClassInside;
> Makes me feel like Java, with all the superfluous indirections.
> And class templates also allow for function templates as static member
> functions.

Yes, it's a little more typing, but I think that it makes things a lot clearer.

"Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:akdcn1$1rs5$1@digitaldaemon.com...
>
> "Walter" <walter@digitalmars.com> wrote in message
> Why would you need to pass on a completely dependent type as a seperate
type
> parameter?

As a template specialization of a more general template.

> But how could you write a template with two arguments, one partially dependent on the other? Is this OK? :
>
> template AdvancedList(E, F) { ... }
>
> template Thingy(A, B : instance AdvancedList(A, C)) { ... }

Yes.

> template Bar(D, D : D[]) { }
>
> Is this valid?! You should give unique names to your type parameters. The
> first type parameter is called "D", and the second?
> Also I find bewildering the syntax:
> D : D[]
> Does this mean that the second type parameter "D" is an array composed of
> elements of its own type? (Infinite recursion)

Hmm. Perhaps I goofed <g>.

I though of another extention to that idea. How about if there is a collision (overload), the user would have to do this...

import max(int)
import max(float)

int.max(a,b);
float.max(x,y);

That way it's simular to how D handles other overloading.

PS
I haven't been able to use this newgroup for a while, my computer crashed
and I've spent several days repairing it. Darn XP.


"Pavel Minayev" <evilone@omen.ru> wrote in message news:CFN374907807516898@news.digitalmars.com...
> On Thu, 22 Aug 2002 18:45:44 +0800 "anderson" <anderson@firestar.com.au>
wrote:
>
> > I was wondering about this syntax sugar.
> >
> >     //Where foo is an template
> >     import foo(int);
> >
> > Then you could use all the methods like C functions.
> >
> >     x = Max(a,b);
> >
> > Ofcourse problems would occur when there are more then one...
> >
> >     import foo(int);
> >     import foo(float);
> >
> > But the complier could work that out.
>
> Yes, just as if the function was overloaded (and any clashes like foo(int)
> declared
> twice are considered errors). I like this!

Sounds good

"Mac Reiter" <Mac_member@pathlink.com> wrote in message news:ak2tg7$1p28$1@digitaldaemon.com...
> (The following message represents me thinking and typing at the same time.
It
> thus flows along my stream of consciousness, and my opinions change as it progresses.  Please read the entire post before replying...)
>
> Since 'import' already has a meaning, and since D templates do share many features in common with namespaces, would 'using' be a better keyword?
>
> using foo(int);
>
> or, to be more complete and provide more flexibility:
>
> using template foo(int);  // moves all template members into current
namespace
> using foo(int).Max;       // only moves Max into current namespace
>
> If you attempted to bring in entire multiple instantiations of the same template, that could probably just be outlawed.  Since you would have to
do the
> equivalent of a scope resolution at every usage to tell the compiler what
to do
> (since *all* of the names would have collided), you might as well have
just done
> that and skipped the 'using' step.
>
> If you brought in different pieces of the same template, but from
different
> instantiations:
>
> using foo(int).Max;
> using foo(double).Min;
>
> then there would be no namespace collision, and it might be allowable.
Horribly
> confusing, in the example given above, but possibly useful in some
situations...
>
> Overall, I think that the 'using template foo(int);' form would be a handy addition for people who only needed a single instantiation of the template
and
> didn't want to have to precede every template member usage with 'intfoo.'. Trying to extend the usage beyond that, however, causes more problems than
it
> solves.
>
> Which leads me to my favorite solution so far, and it is even already in
the
> language (at least in the syntax, even if the template usage of it may not
be in
> the compiler yet) -- 'with'!
>
> with foo(int)
> {
> x = Max(a,b);
> // more stuff, obviously
> }
>
> or maybe:
>
> with inst foo(int)
> {
> }
>
> or:
>
> inst foo(int) intfoo;
> with intfoo
> {
> }
>
> This saves adding another template specific keyword, explains how name collisions will be resolved (innermost 'with' clause that contains such a
member
> will win), and just generally seems nice and clean to me...  That may be
my
> Visual Basic experience coming back to me (VB also uses 'with', and you
use it a
> LOT when you start getting OOPed in VB).
>
> Mac
>
> In article <ak2f15$179g$1@digitaldaemon.com>, anderson says...
> >
> >Wow, one day since this was posted and all these emails.
> >
> >I was wondering about this syntax sugar.
> >
> >    //Where foo is an template
> >    import foo(int);
> >
> >Then you could use all the methods like C functions.
> >
> >    x = Max(a,b);
> >
> >Ofcourse problems would occur when there are more then one...
> >
> >    import foo(int);
> >    import foo(float);
> >
> >But the complier could work that out.
> >
> >"Walter" <walter@digitalmars.com> wrote in message news:ajvgsb$6gt$1@digitaldaemon.com...
> >> www.digitalmars.com/template.html
> >>
> >> Notice how short it is <g>. Ok, what did I miss?
> >>
> >>
> >
> >
>
>