"Walter" <walter@digitalmars.com> wrote in message news:agajj6$1h6g$1@digitaldaemon.com...

> "Juan Carlos Arevalo Baeza" <jcab@roningames.com> wrote in message news:ag5j9q$29lv$1@digitaldaemon.com...
>
> >    What alternative could there be? Looking up _all_ names at the point
of
> > instantiation? I'm really curious.
> >    Or am I missing something here?
>
> The DMC++ compiler collects the template definition as a list of tokens,
and
> then inserts it into the source at the point of instantiation. So, all symbol table lookups are done at the point of instantiation. I believe
that
> is a much more understandable rule (easy to explain) than the confusing
and
> subtle difference in behavior between dependent and non-dependent names.

   It's simpler to explain, but it differs from the normal behavior of
lookups. As in:

---
void func(int) {}
template < class T >
void tfunc()
{
  func('a');
}
void func(char) {}

int main()
{
  tfunc<float>(); // calls func(char)
  return 0;
}
---

   where if tfunc() is made non-template, it'll call func(int) instead.

   The distinction between dependent and non-dependent names is meant to
lessen that difference. That makes it quite obviously good, IMHO.

   It does make the compiler harder to make, though, I'll agree to that :)
Your solution is elegantly simple. I assume you'll make it "the law" for D's
generics when it comes to that.

Salutaciones,
                         JCAB

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:agclqa$iaq$1@digitaldaemon.com...
> Seems like it should only have access to:
>
> 1) The symbols available at the point of template declaration 2) The symbols injected into the template as template parameters 3) Symbols local to the template
>
> Sean

To me either the symbols from the point of declaration or the point of instantiation, not a mish-mash of both.

"Juan Carlos Arevalo Baeza" <jcab@roningames.com> wrote in message news:agcmvq$jjf$1@digitaldaemon.com...
>    It does make the compiler harder to make, though, I'll agree to that :)
> Your solution is elegantly simple. I assume you'll make it "the law" for
D's
> generics when it comes to that.

D does it one better. The symbol table is generated before the templates are processed, so all the symbols in the file are available, not just the ones lexically preceding it.

"Walter" <walter@digitalmars.com> wrote in news:age1p7$1vei$2 @digitaldaemon.com:

> 
> "Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:agclqa$iaq$1@digitaldaemon.com...
>> Seems like it should only have access to:
>>
>> 1) The symbols available at the point of template declaration 2) The symbols injected into the template as template parameters 3) Symbols local to the template
>>
>> Sean
> 
> To me either the symbols from the point of declaration or the point of instantiation, not a mish-mash of both.
> 
> 

Symbols from the point of declaration whould fit the function model best. In a function I can use values passed in as parameters, values in my current global namespace or object namespace at the point of definition.

However taking symbols from the point of instantiation could be quite interesting.  Could a function declared outside of an object be used as a member function?

I don't know what our template syntax will be so I'll just make it up. :-)

template<>
char[] getName()
{
  return name;
}

class foo { char[] name; }
class bar { char[] name; }

a = new foo;
b = new bar;

a.getName();
b.getName();

Or, better yet, if you require explicit instantiation.

class foo
{
  char[] name;

  templatedef getName();  // foo now has GetName member;
}

Hmm. I don't think that should work!

"Patrick Down" <pat@codemoon.com> wrote in message news:Xns9246524F06ABDpatcodemooncom@63.105.9.61...
> "Walter" <walter@digitalmars.com> wrote in news:age1p7$1vei$2 @digitaldaemon.com:
>
> >
> > "Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:agclqa$iaq$1@digitaldaemon.com...
> >> Seems like it should only have access to:
> >>
> >> 1) The symbols available at the point of template declaration 2) The symbols injected into the template as template parameters 3) Symbols local to the template
> >>
> >> Sean
> >
> > To me either the symbols from the point of declaration or the point of instantiation, not a mish-mash of both.
> >
> >
>
> Symbols from the point of declaration whould fit the function model best. In a function I can use values passed in as parameters, values in my current global namespace or object namespace at the point of definition.
>
> However taking symbols from the point of instantiation could be quite interesting.  Could a function declared outside of an object be used as a member function?
>
> I don't know what our template syntax will be so I'll just make it up. :-)
>
> template<>
> char[] getName()
> {
>   return name;
> }
>
> class foo { char[] name; }
> class bar { char[] name; }
>
> a = new foo;
> b = new bar;
>
> a.getName();
> b.getName();
>
> Or, better yet, if you require explicit instantiation.
>
> class foo
> {
>   char[] name;
>
>   templatedef getName();  // foo now has GetName member;
> }
>
>

sweet

but hopefully there's some rule about what scope the template instantiation uses

Perhaps it can first try to use the scope of its declaration

and if that fails, try the scope of the point of instantiation

Sean

"Walter" <walter@digitalmars.com> wrote in message news:age66h$24qt$1@digitaldaemon.com...
>
> "Juan Carlos Arevalo Baeza" <jcab@roningames.com> wrote in message news:agcmvq$jjf$1@digitaldaemon.com...
> >    It does make the compiler harder to make, though, I'll agree to that
:)
> > Your solution is elegantly simple. I assume you'll make it "the law" for
> D's
> > generics when it comes to that.
>
> D does it one better. The symbol table is generated before the templates
are
> processed, so all the symbols in the file are available, not just the ones lexically preceding it.

Then I would pick the point of declaration;  however you still need to be able to "inject" symbols via template parameters that aren't otherwise available at the point of template declaration.

The template writer has no idea what symbols will be available at point of instantiation and cannot rely on having all its needed symbols present.  So point of instantiation seems like a bad choice.

Sean

"Walter" <walter@digitalmars.com> wrote in message news:age1p7$1vei$2@digitaldaemon.com...
>
> "Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:agclqa$iaq$1@digitaldaemon.com...
> > Seems like it should only have access to:
> >
> > 1) The symbols available at the point of template declaration 2) The symbols injected into the template as template parameters 3) Symbols local to the template
> >
> > Sean
>
> To me either the symbols from the point of declaration or the point of instantiation, not a mish-mash of both.

"Walter" <walter@digitalmars.com> wrote in news:agf4b6$ho7$2@digitaldaemon.com:

> Hmm. I don't think that should work!
> 
> "Patrick Down" <pat@codemoon.com> wrote in message news:Xns9246524F06ABDpatcodemooncom@63.105.9.61...
>> "Walter" <walter@digitalmars.com> wrote in news:age1p7$1vei$2 @digitaldaemon.com:
>>
>>
>> However taking symbols from the point of instantiation could be quite interesting.  Could a function declared outside of an object be used as a member function?
>>
>> I don't know what our template syntax will be so I'll just make it up. :-)
>>
>> template<>
>> char[] getName()
>> {
>>   return name;
>> }
>>
>> class foo { char[] name; }
>> class bar { char[] name; }
>>
>> a = new foo;
>> b = new bar;
>>
>> a.getName();
>> b.getName();

Well even I will admit that the attaching a template function like above is pretty silly.

>>
>> Or, better yet, if you require explicit instantiation.
>>
>> class foo
>> {
>>   char[] name;
>>
>>   templatedef getName();  // foo now has GetName member;
>> }

However the explicit template instantiation above has some merit I think.  It's a way to implement mixins.

"Walter" <walter@digitalmars.com> wrote in message news:age66h$24qt$1@digitaldaemon.com...

> D does it one better. The symbol table is generated before the templates
are
> processed, so all the symbols in the file are available, not just the ones lexically preceding it.

   Right! That makes it substantially better.

   Still see a problem with templates exported from a module and used in
several other modules. Ironically, C/C++'s system of using textual include
files for module handling makes this point pretty much moot.

   Personally, I don't think there's a perfect solution, no matter how you
do it.

Salutaciones,
                         JCAB

"Walter" <walter@digitalmars.com> wrote in message news:agf4b6$ho7$2@digitaldaemon.com...

> "Patrick Down" <pat@codemoon.com> wrote in message news:Xns9246524F06ABDpatcodemooncom@63.105.9.61...
>
> > I don't know what our template syntax will be so I'll just make it up. :-)
> >
> > template<>
> > char[] getName()
> > {
> >   return name;
> > }
> >
> > ...
>
> Hmm. I don't think that should work!

template< class T >
char[] T::getName()
{
  return name;
}

   As far as expressivity is concerned, this type of thing should be doable.
It's definitely no more ambiguous than operator overloading in C++.

Salutaciones,
                         JCAB