Re: Namespace request
Jason Gade wrote:
>
> Al Getz wrote:
> >
> > Jason Gade wrote:
> > >
> > > Al Getz wrote:
> > > >
> > > > Jason Gade wrote:
> > > > >
> > > > > Rob, can you change namespacing so that more than one file can be
> > > > > included
> > into</font></i>
> > > > > the same namespace?
> > > > >
> > > > > Here is an example of what I want to do:
> > > > >
> > > > > include misc.e as rds
> > > > > include machine.e as rds
> > > > > include dll.e as rds
> > > > >
> > > > > Currently the interpreter gives an error.
> > > > >
> > > > > Rationale: I want to use namespaces in a file that is intended to be
> > > > > included
> > > > > by another so as to avoid conflicts in user programs. But when I know
> > > > > that
> > there</font></i>
> > > > > will be no conflicts within the files that I'm including I don't want
> > > > > to
> make</font></i>
> > > > > a new namespace for every single include. This will also help prevent
> > > > > namespace
> > > > > pollution by reducing the number of unique namespaces that a program
> > > > > needs
> to</font></i>
> > > > > come up with.
> > > >
> > > > Hi there,
> > > >
> > > >
> > > > So i guess you're saying you want to include multiple files under the
> > > > same namespace so functions can be called in multiple files using
> > > > the same prefix...interesting...
> > >
> > > Yes. That's the way it works in C++, several related includes are part of
> > > the
> > > same namespace. C++ also has the 'using namespace' keyword.
> > >
> > > But right now I'm looking through the listserv archives to understand
> > > better
> > > how namespace rules actually work. I've noticed so far that they don't
> > > exactly
> > > do what I think they do.
> > >
> > > So far I've found that using namespaces within a library won't prevent
> > > symbol
> > > conflicts in user programs, though using them might make them easier to
> > > fix.
> > > The user program will still have to use a namespace when a conflict
> > > arises.
> > >
> > > By my example, I don't really expect there to be a symbol conflict with
> > > RDS
> > > libs, but I was trying to be "future proof" and protect the user from
> > > having
> > > to worry about 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
> > > j.
> >
> > Hi again,
> >
> > I guess there are good points to this and bad points, but i havent
> > thought it all through myself yet.
> > I wanted to be able to include the same file more than once (which
> > would be easy in the source code) and have it load again so that
> > local variables get repeated:
> >
> > --Start Manager.ew
> > atom a
> > global procedure LoadA(atom x)
> > a=x
> > end procedure
> > global function GetA()
> > return a
> > end function
> > --End Manager.ew
> >
> > include Manager.ew as M1
> > include Manager.ew as M2
> >
> > M1:LoadA(10)
> > M2:LoadA(20)
> >
> > ?M1:GetA() --prints "10"
> > ?M2:GetA() --prints "20"
> >
> > Currently, you have to copy and rename Manager.ew and included it a second
> > time with it's new name
> > include Manager1.ew as M1
> > include Manager2.ew as M2
> >
> > If we could include the same file twice and get a new instance loaded
> > (as per code far above) we would be able to handle files as entire
> > objects, which would increase the functionality of Euphoria quite a bit.
> > Imagine being able to write a 'class' file as an include file that had
> > all kinds of functionality including functions AND data structures,
> > and in one line be able to repeat that 'object'
> > include MyClass.ew as Class1
> > include MyClass.ew as Class2
> >
> > Add to that the ability to index and WOW we've got incredible functionality:
> > Class={1,2,3,4,5}
> > for k=1 to 5 do
> > include MyClass.ew as Class[k]
> > end for
> > and suddenly we can index entire classes:
> > data1=Class[1]:data
> > data2=Class[2]:data
> > etc.
> >
> > WOW!!!!!!!!
> >
> >
> > Al
> >
> >
> > My bumper sticker: "I brake for LED's"
>
> I really wish that it worked that way, too. I've lobbied for it in the past
<snip>
He he, yeah :)
I think that neither Rob nor anyone else truely understands the power
of programming that would come out of something like this. To be able
to declare a class the same way you declare a variable like 'atom x'
is quite a powerful programming technique, and the logic behind it
stems from the way a language progresses anyway:
You start with variables, which you include by declaring them:
atom a
You move toward 'groups' of these things:
sequence s
s={0,1,23,4}
You add function calls:
x=myfunc()
You add 'include' files which allow you to keep functions and
data (variables) in the same file as a set of functions and data.
A logical next step is to be able to declare your built up
function/data groups as a single object which can be repeated
the same way you declare a 'normal' variable:
Normal var (Euphoria allows many atoms to be declared):
atom a
atom b
Group (Class):
include MyGroup.ew as MG1
include MyGroup.ew as MG2
and now we have two groups to use as well as two atoms.
Maybe a better wording would have been:
atom a,b
group("MyGroup.ew") MG1, MG2
so it ends up being something like a 'type', only a prefix instead.
I guess another keyword would be more clear:
include class MyGroup.ew as MG1
include class MyGroup.ew as MG2
ie a Euphoria with classes :) (the word 'include' is optional).
Euphoria allows you to 'include' as many atoms and sequences as
you care to declare, so why not allow you to include (declare) as
many custom built objects as you care to ?
Think also about how fast it would be to wrap a class object?
You wouldnt have to try to 'sequence the living carp' out of
everything he he :) (ie stick every dang thing into some sequence
somewhere AND maintain them all).
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
|
Not Categorized, Please Help
|
|
