Re: Name-space proposal
Hi Jason,
namespaces could be improve by authorising named block inside files at
multi-level like this
namespace some_name
code here
namespace other_name
code here
end namespace -- other_name
end namespace -- some_name
anything not defined as global should be private to its namespace
to access sublevel of namespaces one use a path like this:
some_name:other_name:global_indentifier
two new keywords should be added "namespace" and
"filelocal" to extend the scope of an identifier outside its namespace to the
whole file.
so inside a namespace an identifier could be defined 3 ways:
1) object o -- private to its namespace
2) filelocal object o -- visible to the whole file.
3) global object o -- visible everywhere.
now we would have something like that
-- in math.e
namespace trigo
global function htan(atom a) hyperbolic tangeant
...
end function
.
.
etc ...
end namespace
namespace matrix
global function matrix_inv(sequence m) -- return the inverse of matrix m
...
end function
end namespace
-- in main file
include math.e
? trigo:htan(45)
? matrix:matrix_inv(m)
the idea is borrowed from C#
regards,
Jacques Deschênes
Jason Gade wrote:
>
> jacques deschênes wrote:
> >
> > Hi Robert,
> > I tested it and that is true. I confounded that situation with this one:
> >
> > --test.e
> > global constant test=123
> >
> > --test2.e
> > global constant test=345
> >
> > --main.ex
> > include test.e
> > include test2.e
> > ? test
> >
> > which result in this:
> > C:\Temp\main.ex:3
> > A namespace qualifier is needed to resolve test.
> > test is defined as a global symbol in:
> > c:\temp\test.e
> > c:\temp\test2.e
> >
> >
> > regards,
> > Jacques Deschênes
> Situations like this is why namespaces were introduced in the first place. In
> this case, you *have* to use namespaces. Unfortunately, you have to use
> namespaces
> for both variables, not just one or the other (which would be nice).
>
> The problem lies when two third party libraries include the same symbol
> without
> a namespace qualifier. Then you have to edit the libraries to fix it. That's
> why libraries should definitely be using namespaces for subordinate includes.
>
> I've got an idea that I want to try with the source, I'll get back to you on
> it.
>
> --
> "Any programming problem can be solved by adding a level of indirection."
> --anonymous
> "Any performance problem can be solved by removing a level of indirection."
> --M. Haertel
> "Premature optimization is the root of all evil in programming."
> --C.A.R. Hoare
> j.
|
Not Categorized, Please Help
|
|