"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:agf603$jcs$1@digitaldaemon.com...
> Just let them clarify the import or hide an imported function, that gives them a way to resolve conflicts, and doesn't prevent people from doing reasonable things because you think it's good for them.  I don't want my compiler to be my mom.  Let me shoot myself in the foot if I need to.  ;)

Someone (was it you?) posted the idea of enabling specification of aliases for symbols, this would enable easy (and explicit) replication of a symbol from one module into another. That should resolve the difficulties in your example.

"Walter" <walter@digitalmars.com> wrote in message news:agfqj9$17g9$1@digitaldaemon.com...
>
> "Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:agf603$jcs$1@digitaldaemon.com...
> > Just let them clarify the import or hide an imported function, that
gives
> > them a way to resolve conflicts, and doesn't prevent people from doing reasonable things because you think it's good for them.  I don't want my compiler to be my mom.  Let me shoot myself in the foot if I need to.
;)
>
> Someone (was it you?) posted the idea of enabling specification of aliases for symbols, this would enable easy (and explicit) replication of a symbol from one module into another. That should resolve the difficulties in your example.

I think aliases on symbols are a good idea, (and I think it was me in fact)

Yeah I guess this could work:

import vector2;
import vector3;

alias vector2.dot dot; // pull them both into this module alias vector3.dot dot;

// now the overloading works as expected

int main()
{
    vector3 a;
    vector2 b;
    float val = Dot(a,a) + Dot(b,b);
    return 0;
}

Some variant of import syntax would also work for this particular issue:

import vector2;
import vector3;
import vector2.dot;
import vector3.dot;


Sean

Most definitely. Surely this is analogous to the using ::ns::sym; C++ syntax, and should be used in just the same way, ie. from the using declaration onwards any compilation unit sees all symbols of the same name as equally "visible" resolving your original objection. Or am I missing something?


"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:agghug$1v2m$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:agfqj9$17g9$1@digitaldaemon.com...
> >
> > "Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:agf603$jcs$1@digitaldaemon.com...
> > > Just let them clarify the import or hide an imported function, that
> gives
> > > them a way to resolve conflicts, and doesn't prevent people from doing reasonable things because you think it's good for them.  I don't want
my
> > > compiler to be my mom.  Let me shoot myself in the foot if I need to.
> ;)
> >
> > Someone (was it you?) posted the idea of enabling specification of
aliases
> > for symbols, this would enable easy (and explicit) replication of a
symbol
> > from one module into another. That should resolve the difficulties in
your
> > example.
>
> I think aliases on symbols are a good idea, (and I think it was me in
fact)
>
> Yeah I guess this could work:
>
> import vector2;
> import vector3;
>
> alias vector2.dot dot; // pull them both into this module alias vector3.dot dot;
>
> // now the overloading works as expected
>
> int main()
> {
>     vector3 a;
>     vector2 b;
>     float val = Dot(a,a) + Dot(b,b);
>     return 0;
> }
>
> Some variant of import syntax would also work for this particular issue:
>
> import vector2;
> import vector3;
> import vector2.dot;
> import vector3.dot;
>
>
> Sean
>
>

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message
news:agghug$1v2m$1@digitaldaemon.com...
<SNIP>
>
> I think aliases on symbols are a good idea, (and I think it was me in
fact)
>
> Yeah I guess this could work:
>
> import vector2;
> import vector3;
>
> alias vector2.dot dot; // pull them both into this module alias vector3.dot dot;
>
> // now the overloading works as expected
>
<SNIP>
>
> Sean
>

Good ideas!
I love it when everyone agrees!  :)
I especially like the notion of being able to alias any
symbol to any other, it could be very handy for resolving
all kinds of issues when porting or modifying code.


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail

Right, except it shouldn't be dependent on lexical order.

Sean

"Matthew Wilson" <matthew@thedjournal.com> wrote in message news:aggioi$1vpg$1@digitaldaemon.com...
> Most definitely. Surely this is analogous to the using ::ns::sym; C++ syntax, and should be used in just the same way, ie. from the using declaration onwards any compilation unit sees all symbols of the same name as equally "visible" resolving your original objection. Or am I missing something?
>
>
> "Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:agghug$1v2m$1@digitaldaemon.com...
> > "Walter" <walter@digitalmars.com> wrote in message news:agfqj9$17g9$1@digitaldaemon.com...
> > >
> > > "Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:agf603$jcs$1@digitaldaemon.com...
> > > > Just let them clarify the import or hide an imported function, that
> > gives
> > > > them a way to resolve conflicts, and doesn't prevent people from
doing
> > > > reasonable things because you think it's good for them.  I don't
want
> my
> > > > compiler to be my mom.  Let me shoot myself in the foot if I need
to.
> > ;)
> > >
> > > Someone (was it you?) posted the idea of enabling specification of
> aliases
> > > for symbols, this would enable easy (and explicit) replication of a
> symbol
> > > from one module into another. That should resolve the difficulties in
> your
> > > example.
> >
> > I think aliases on symbols are a good idea, (and I think it was me in
> fact)
> >
> > Yeah I guess this could work:
> >
> > import vector2;
> > import vector3;
> >
> > alias vector2.dot dot; // pull them both into this module alias vector3.dot dot;
> >
> > // now the overloading works as expected
> >
> > int main()
> > {
> >     vector3 a;
> >     vector2 b;
> >     float val = Dot(a,a) + Dot(b,b);
> >     return 0;
> > }
> >
> > Some variant of import syntax would also work for this particular issue:
> >
> > import vector2;
> > import vector3;
> > import vector2.dot;
> > import vector3.dot;
> >
> >
> > Sean
> >
> >
>
>

It has to, surely?

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:aglktd$m1i$1@digitaldaemon.com...
> Right, except it shouldn't be dependent on lexical order.
>
> Sean
>
> "Matthew Wilson" <matthew@thedjournal.com> wrote in message news:aggioi$1vpg$1@digitaldaemon.com...
> > Most definitely. Surely this is analogous to the using ::ns::sym; C++ syntax, and should be used in just the same way, ie. from the using declaration onwards any compilation unit sees all symbols of the same
name
> > as equally "visible" resolving your original objection. Or am I missing something?
> >
> >
> > "Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:agghug$1v2m$1@digitaldaemon.com...
> > > "Walter" <walter@digitalmars.com> wrote in message news:agfqj9$17g9$1@digitaldaemon.com...
> > > >
> > > > "Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:agf603$jcs$1@digitaldaemon.com...
> > > > > Just let them clarify the import or hide an imported function,
that
> > > gives
> > > > > them a way to resolve conflicts, and doesn't prevent people from
> doing
> > > > > reasonable things because you think it's good for them.  I don't
> want
> > my
> > > > > compiler to be my mom.  Let me shoot myself in the foot if I need
> to.
> > > ;)
> > > >
> > > > Someone (was it you?) posted the idea of enabling specification of
> > aliases
> > > > for symbols, this would enable easy (and explicit) replication of a
> > symbol
> > > > from one module into another. That should resolve the difficulties
in
> > your
> > > > example.
> > >
> > > I think aliases on symbols are a good idea, (and I think it was me in
> > fact)
> > >
> > > Yeah I guess this could work:
> > >
> > > import vector2;
> > > import vector3;
> > >
> > > alias vector2.dot dot; // pull them both into this module alias vector3.dot dot;
> > >
> > > // now the overloading works as expected
> > >
> > > int main()
> > > {
> > >     vector3 a;
> > >     vector2 b;
> > >     float val = Dot(a,a) + Dot(b,b);
> > >     return 0;
> > > }
> > >
> > > Some variant of import syntax would also work for this particular
issue:
> > >
> > > import vector2;
> > > import vector3;
> > > import vector2.dot;
> > > import vector3.dot;
> > >
> > >
> > > Sean
> > >
> > >
> >
> >
>
>

It has to, surely?

If not, doesn't this leave us in the same non-deterministic (or at least unpredictable / invisible) position, whereby the introduction of a symbol "lower down" in the particular scope's visibility causes unforeseen/unintended side-effects to code that shouldn't be able to see it?

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:aglktd$m1i$1@digitaldaemon.com...
> Right, except it shouldn't be dependent on lexical order.
>
> Sean
>
> "Matthew Wilson" <matthew@thedjournal.com> wrote in message news:aggioi$1vpg$1@digitaldaemon.com...
> > Most definitely. Surely this is analogous to the using ::ns::sym; C++ syntax, and should be used in just the same way, ie. from the using declaration onwards any compilation unit sees all symbols of the same
name
> > as equally "visible" resolving your original objection. Or am I missing something?
> >
> >
> > "Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:agghug$1v2m$1@digitaldaemon.com...
> > > "Walter" <walter@digitalmars.com> wrote in message news:agfqj9$17g9$1@digitaldaemon.com...
> > > >
> > > > "Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:agf603$jcs$1@digitaldaemon.com...
> > > > > Just let them clarify the import or hide an imported function,
that
> > > gives
> > > > > them a way to resolve conflicts, and doesn't prevent people from
> doing
> > > > > reasonable things because you think it's good for them.  I don't
> want
> > my
> > > > > compiler to be my mom.  Let me shoot myself in the foot if I need
> to.
> > > ;)
> > > >
> > > > Someone (was it you?) posted the idea of enabling specification of
> > aliases
> > > > for symbols, this would enable easy (and explicit) replication of a
> > symbol
> > > > from one module into another. That should resolve the difficulties
in
> > your
> > > > example.
> > >
> > > I think aliases on symbols are a good idea, (and I think it was me in
> > fact)
> > >
> > > Yeah I guess this could work:
> > >
> > > import vector2;
> > > import vector3;
> > >
> > > alias vector2.dot dot; // pull them both into this module alias vector3.dot dot;
> > >
> > > // now the overloading works as expected
> > >
> > > int main()
> > > {
> > >     vector3 a;
> > >     vector2 b;
> > >     float val = Dot(a,a) + Dot(b,b);
> > >     return 0;
> > > }
> > >
> > > Some variant of import syntax would also work for this particular
issue:
> > >
> > > import vector2;
> > > import vector3;
> > > import vector2.dot;
> > > import vector3.dot;
> > >
> > >
> > > Sean
> > >
> > >
> >
> >
>
>

Why should it have to?

Don't limit yourself to what C and C++ offer you.  Look at C#; it also has no dependence on lexical order of declarations.  So long as they're in the same scope it's ok.  C++ does this too but only within a class declaration.

Maybe it should work like all the other D attributes.  Either

using mymodule.myfunction :

myfunction();

or

using mymodule.myfunction
{
    myfunction();
}

Sean


"Matthew Wilson" <matthew@thedjournal.com> wrote in message news:agloqe$pc5$1@digitaldaemon.com...
> It has to, surely?
>
> "Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:aglktd$m1i$1@digitaldaemon.com...
> > Right, except it shouldn't be dependent on lexical order.
> >
> > Sean
> >
> > "Matthew Wilson" <matthew@thedjournal.com> wrote in message news:aggioi$1vpg$1@digitaldaemon.com...
> > > Most definitely. Surely this is analogous to the using ::ns::sym; C++ syntax, and should be used in just the same way, ie. from the using declaration onwards any compilation unit sees all symbols of the same
> name
> > > as equally "visible" resolving your original objection. Or am I
missing
> > > something?

Why should "upper" and "lower" have any special distinction?

Why should "prior" and "subsequent" have any special distinction?

It's either visible in the scope, or it's not.

Sean

"Matthew Wilson" <matthew@thedjournal.com> wrote in message news:aglot4$pgp$1@digitaldaemon.com...
> It has to, surely?
>
> If not, doesn't this leave us in the same non-deterministic (or at least unpredictable / invisible) position, whereby the introduction of a symbol "lower down" in the particular scope's visibility causes unforeseen/unintended side-effects to code that shouldn't be able to see
it?
>
> "Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:aglktd$m1i$1@digitaldaemon.com...
> > Right, except it shouldn't be dependent on lexical order.
> >
> > Sean
> >
> > "Matthew Wilson" <matthew@thedjournal.com> wrote in message news:aggioi$1vpg$1@digitaldaemon.com...
> > > Most definitely. Surely this is analogous to the using ::ns::sym; C++ syntax, and should be used in just the same way, ie. from the using declaration onwards any compilation unit sees all symbols of the same
> name
> > > as equally "visible" resolving your original objection. Or am I
missing
> > > something?
> > >
> > >
> > > "Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:agghug$1v2m$1@digitaldaemon.com...
> > > > "Walter" <walter@digitalmars.com> wrote in message news:agfqj9$17g9$1@digitaldaemon.com...
> > > > >
> > > > > "Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:agf603$jcs$1@digitaldaemon.com...
> > > > > > Just let them clarify the import or hide an imported function,
> that
> > > > gives
> > > > > > them a way to resolve conflicts, and doesn't prevent people from
> > doing
> > > > > > reasonable things because you think it's good for them.  I don't
> > want
> > > my
> > > > > > compiler to be my mom.  Let me shoot myself in the foot if I
need
> > to.
> > > > ;)
> > > > >
> > > > > Someone (was it you?) posted the idea of enabling specification of
> > > aliases
> > > > > for symbols, this would enable easy (and explicit) replication of
a
> > > symbol
> > > > > from one module into another. That should resolve the difficulties
> in
> > > your
> > > > > example.
> > > >
> > > > I think aliases on symbols are a good idea, (and I think it was me
in
> > > fact)
> > > >
> > > > Yeah I guess this could work:
> > > >
> > > > import vector2;
> > > > import vector3;
> > > >
> > > > alias vector2.dot dot; // pull them both into this module alias vector3.dot dot;
> > > >
> > > > // now the overloading works as expected
> > > >
> > > > int main()
> > > > {
> > > >     vector3 a;
> > > >     vector2 b;
> > > >     float val = Dot(a,a) + Dot(b,b);
> > > >     return 0;
> > > > }
> > > >
> > > > Some variant of import syntax would also work for this particular
> issue:
> > > >
> > > > import vector2;
> > > > import vector3;
> > > > import vector2.dot;
> > > > import vector3.dot;
> > > >
> > > >
> > > > Sean
> > > >
> > > >
> > >
> > >
> >
> >
>
>
>
>