1. Store Includes
- Posted by DB James <larch at adelphia.net>
Jul 17, 2005
-
Last edited Jul 18, 2005
Hi all,
I have not posted in awhile, but I've been around. Thanks to all who have
posted in keeping the more quiet of us informed and interested.
Anyway, I have a new program up and I hope you'll have a look at it, tell me
what you think, give it a try, and report any problems.
The program is called StoreInc.ex. It is a DOS program that performs the
same function as Tone Skoda's GetEuIncs.exw, that is, after the user selects
an Eu program, it creates a sub-folder, copies the program into it, and adds
all the includes of the program. This is very useful for a couple of
reasons: in zipping and submitting a program to the Eu site, it assures that
all includes are, er, included. Also it makes a "fixed moment in history"
for the program such that at a later time one does not have to guess what
versions of include files were used.
Why did I duplicate Tone's work? Well, I like DOS and wanted a version for
it. I didn't look at Tone's code, I just dived in for the sake of tackling
a goal I thought was within reach of my current abilities, yet would stretch
my skills. Another reason was to use a set of routines I have created over
time that I call BoxGUI. These are dirt-simple ways of making DOS more
accessible, but not using the "Windows" concept of how to do things. In
StoreInc.ex, for example, the command line is not used. The user can
navigate to and select the file directly.
A last point: you might want to take a look at the program for one particular
feature: it has no include files of its own. All necessary components are
within one file. This was done by means of two programs I'll be posting
soon: IncAll.ex and Mash.ex. These create a large file of all files, then
strip out all unused items. You will perhaps smile when I confess the
impetus behind these: I use personal include files I don't want to inflict
on anyone I don't hate :^D There are things with tentacles in there! By
"mashing" the files, the world only sees what works (more or less). More
seriously, there might be times when it would be useful to send someone
who is not an Eu person just two files: the PD interpreter and the program
itself.
Over,
--Quark
2. Re: Store Includes
DB James wrote:
>
> Hi all,
>
> I have not posted in awhile, but I've been around. Thanks to all who have
> posted in keeping the more quiet of us informed and interested.
>
> Anyway, I have a new program up and I hope you'll have a look at it, tell me
> what you think, give it a try, and report any problems.
>
> The program is called StoreInc.ex. It is a DOS program that performs the
> same function as Tone Skoda's GetEuIncs.exw, that is, after the user selects
> an Eu program, it creates a sub-folder, copies the program into it, and adds
> all the includes of the program. This is very useful for a couple of
> reasons: in zipping and submitting a program to the Eu site, it assures that
> all includes are, er, included. Also it makes a "fixed moment in history"
> for the program such that at a later time one does not have to guess what
> versions of include files were used.
>
> Why did I duplicate Tone's work? Well, I like DOS and wanted a version for
> it. I didn't look at Tone's code, I just dived in for the sake of tackling
> a goal I thought was within reach of my current abilities, yet would stretch
> my skills. Another reason was to use a set of routines I have created over
> time that I call BoxGUI. These are dirt-simple ways of making DOS more
> accessible, but not using the "Windows" concept of how to do things. In
> StoreInc.ex, for example, the command line is not used. The user can
> navigate to and select the file directly.
>
> A last point: you might want to take a look at the program for one particular
> feature: it has no include files of its own. All necessary components are
> within one file. This was done by means of two programs I'll be posting
> soon: IncAll.ex and Mash.ex. These create a large file of all files, then
> strip out all unused items. You will perhaps smile when I confess the
> impetus behind these: I use personal include files I don't want to inflict
> on anyone I don't hate :^D There are things with tentacles in there! By
> "mashing" the files, the world only sees what works (more or less). More
> seriously, there might be times when it would be useful to send someone
> who is not an Eu person just two files: the PD interpreter and the program
> itself.
>
> Over,
>
> --Quark
>
Hi there,
Sounds interesting...im just wondering now...
does it work with Euphoria's name space feature too?
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
3. Re: Store Includes
Al Getz wrote:
>
> DB James wrote:
> >
> > Hi all,
<snip>
> > A last point: you might want to take a look at the program for one
> > particular
> > feature: it has no include files of its own. All necessary components are
> > within one file. This was done by means of two programs I'll be posting
> > soon: IncAll.ex and Mash.ex. These create a large file of all files, then
> > strip out all unused items. You will perhaps smile when I confess the
> > impetus behind these: I use personal include files I don't want to inflict
> > on anyone I don't hate :^D There are things with tentacles in there! By
> > "mashing" the files, the world only sees what works (more or less). More
> > seriously, there might be times when it would be useful to send someone
> > who is not an Eu person just two files: the PD interpreter and the program
> > itself.
> >
> > Over,
> >
> > --Quark
> >
>
> Hi there,
>
> Sounds interesting...im just wondering now...
> does it work with Euphoria's name space feature too?
>
>
> Take care,
> Al
Hi Al,
I assume it was that last paragraph that you were responding to. As all
includes are mashed with the original program into the same file, there
are no includes and no global variables. There can be no duplicated
items either of any kind. The programmer must fix all duplicate names.
In a sense, all namespace issues seem to come down to nullifying
duplicate names somehow. With mashing, it is simply explicit -- NO
duplicate names. However, in fixing these duplicate names, there
is no effect on existing libraries as they are not involved --
only the items in the mashed file.
Your question has made me rethink how to handle this problem --
I'll change the action of mash.ex to warn the programmer of all duplicates
and let that person do the (usually) few fixes of the mashed code.
Was all that to the point of your question, Al?
--Quark
4. Re: Store Includes
- Posted by Al Getz <Xaxo at aol.com>
Jul 18, 2005
-
Last edited Jul 19, 2005
DB James wrote:
>
> Al Getz wrote:
> >
> > DB James wrote:
> > >
> > > Hi all,
> <snip>
> > > A last point: you might want to take a look at the program for one
> > > particular
> > > feature: it has no include files of its own. All necessary components are
> > > within one file. This was done by means of two programs I'll be posting
> > > soon: IncAll.ex and Mash.ex. These create a large file of all files, then
> > > strip out all unused items. You will perhaps smile when I confess the
> > > impetus behind these: I use personal include files I don't want to inflict
> > > on anyone I don't hate :^D There are things with tentacles in there! By
> > > "mashing" the files, the world only sees what works (more or less). More
> > > seriously, there might be times when it would be useful to send someone
> > > who is not an Eu person just two files: the PD interpreter and the program
> > > itself.
> > >
> > > Over,
> > >
> > > --Quark
> > >
> >
> > Hi there,
> >
> > Sounds interesting...im just wondering now...
> > does it work with Euphoria's name space feature too?
> >
> >
> > Take care,
> > Al
>
> Hi Al,
>
> I assume it was that last paragraph that you were responding to. As all
> includes are mashed with the original program into the same file, there
> are no includes and no global variables. There can be no duplicated
> items either of any kind. The programmer must fix all duplicate names.
>
> In a sense, all namespace issues seem to come down to nullifying
> duplicate names somehow. With mashing, it is simply explicit -- NO
> duplicate names. However, in fixing these duplicate names, there
> is no effect on existing libraries as they are not involved --
> only the items in the mashed file.
>
> Your question has made me rethink how to handle this problem --
> I'll change the action of mash.ex to warn the programmer of all duplicates
> and let that person do the (usually) few fixes of the mashed code.
>
> Was all that to the point of your question, Al?
>
> --Quark
>
Hi Quark,
Actually, my question was a little more general, but what you are
talking about is good to think about too.
All i really wanted to know was this:
Can you send your program a program file set that uses Euphoria's
namespace feature and have it create a lumped program file
with no namespace prefixes that runs the same as the original
set of files?
I guess ideally you could also make an exw:
include this.e
include that.e
include thisothertoo.e
and send it to your program to create a single file library right?
When you say duplicate names, you mean two names like this:
Window:Create(...)
MyThing:Create(...)
where the 'Create's occur in different files?
Or do you mean something else?
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
5. Re: Store Includes
>
> Hi Quark,
>
> Actually, my question was a little more general, but what you are
> talking about is good to think about too.
>
> All i really wanted to know was this:
>
> Can you send your program a program file set that uses Euphoria's
> namespace feature and have it create a lumped program file
> with no namespace prefixes that runs the same as the original
> set of files?
>
> I guess ideally you could also make an exw:
>
> include this.e
> include that.e
> include thisothertoo.e
>
> and send it to your program to create a single file library right?
>
> When you say duplicate names, you mean two names like this:
>
> Window:Create(...)
> MyThing:Create(...)
>
> where the 'Create's occur in different files?
>
> Or do you mean something else?
>
>
> Take care,
> Al
>
Hi Al,
The first thing that now comes to my mind is "YOW!". I now see the
implications of your question and the answer is "maybe". I am primarily
a DOS programmer, and have those blinders on sometimes when I tackle
things, as was the case with Mash.ex. I hve never used the namespace
convention, but for those who do use it, (perhaps especially in Windows
programming?), it may well be important or critical, for all I know.
I think I can see a way to do what you ask without tossing everything out
and beginning again (or tossing Mash.ex on the heap with other experiments
that didn't work out).
Thinking aloud, if a parse found a namespace item in an include line,
and later a colon'ed reference to a routine or type, then the referred
gizmo could be made into a unique name by prepending the name
of the namespace to it wherever it is found in the appropriate sections
of the code. I so surmise, anyway. That would do what you asked about,
but if the declare were in yet another file (if that ever happens), I think
I'd be sunk. So, Question: are all namespace references to items declared
in the named include file? If so, this is possibly a "go".
Meanwhile, I have used Juergen's file_ln.e to improve the file-handling
of all three programs.
If nothing else comes of all this, I am learning a lot of interesting tricks
in coding and error-reporting. I have a file in C:\Euphoria called
Debug.txt that I load into Edita, and reload it frequently, that shows
what is happening in critical areas of the code as I run tests, because of
writing to that file all the data I need to see. I turn this reporting on
and off as I need to. Very useful.
Thanks for your interest and comments. It is helping a lot.
--Quark
6. Re: Store Includes
DB James wrote:
>
> >
> > Hi Quark,
> >
> > Actually, my question was a little more general, but what you are
> > talking about is good to think about too.
> >
> > All i really wanted to know was this:
> >
> > Can you send your program a program file set that uses Euphoria's
> > namespace feature and have it create a lumped program file
> > with no namespace prefixes that runs the same as the original
> > set of files?
> >
> > I guess ideally you could also make an exw:
> >
> > include this.e
> > include that.e
> > include thisothertoo.e
> >
> > and send it to your program to create a single file library right?
> >
> > When you say duplicate names, you mean two names like this:
> >
> > Window:Create(...)
> > MyThing:Create(...)
> >
> > where the 'Create's occur in different files?
> >
> > Or do you mean something else?
> >
> >
> > Take care,
> > Al
> >
>
> Hi Al,
>
> The first thing that now comes to my mind is "YOW!". I now see the
> implications of your question and the answer is "maybe". I am primarily
> a DOS programmer, and have those blinders on sometimes when I tackle
> things, as was the case with Mash.ex. I hve never used the namespace
> convention, but for those who do use it, (perhaps especially in Windows
> programming?), it may well be important or critical, for all I know.
>
> I think I can see a way to do what you ask without tossing everything out
> and beginning again (or tossing Mash.ex on the heap with other experiments
> that didn't work out).
>
> Thinking aloud, if a parse found a namespace item in an include line,
> and later a colon'ed reference to a routine or type, then the referred
> gizmo could be made into a unique name by prepending the name
> of the namespace to it wherever it is found in the appropriate sections
> of the code. I so surmise, anyway. That would do what you asked about,
> but if the declare were in yet another file (if that ever happens), I think
> I'd be sunk. So, Question: are all namespace references to items declared
> in the named include file? If so, this is possibly a "go".
>
> Meanwhile, I have used Juergen's file_ln.e to improve the file-handling
> of all three programs.
>
> If nothing else comes of all this, I am learning a lot of interesting tricks
> in coding and error-reporting. I have a file in C:\Euphoria called
> Debug.txt that I load into Edita, and reload it frequently, that shows
> what is happening in critical areas of the code as I run tests, because of
> writing to that file all the data I need to see. I turn this reporting on
> and off as I need to. Very useful.
>
> Thanks for your interest and comments. It is helping a lot.
>
> --Quark
>
Hi again Quark,
Hee hee, YOWIE i guess is a good word for it too as there's a little
work involved as im sure you know :)
I think it would be very worthwhile however.
As far as your question goes, i can only see one area of caution:
A function call such as:
x=GetValue()
could very well have been declared inside an include file that got
included via a namespace such as:
include GetValues.ew as GetStuff
Now in that previous line the user decided to skip the namespace prefix so
instead of writing:
x=GetStuff:GetValue()
the previous line was used instead.
This works perfectly well in Euphoria, and as far as i know this
is the way it's always going to work.
Now the default is to use GetValue() without a namespace, but
from my experiance this wouldnt be the greatest idea because we
not only want our program to work now, we want it to work after
we add something else too, so a warning would be great, and
an option to either use the prefix or not use the prefix would
be nice too.
Another situation to be careful about is...
Since new names will appear as the mashing is in progress, they will
have to be checked to make sure there is no other name exactly the same.
Since you wont know all 'till the end of the whole mash process, you'll
have to keep some reference to occurances so you can 'rename' a second
or even third/fourth time if need be. You probably thought about this
already though.
I'd be more than happy to test your program out fully once you think
you've got it to the point where it can handle namespace declares.
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
7. Re: Store Includes
Al Getz wrote:
BEGIN PREVIOUS
Hi again Quark,
Hee hee, YOWIE i guess is a good word for it too as there's a little
work involved as im sure you know :)
I think it would be very worthwhile however.
As far as your question goes, i can only see one area of caution:
A function call such as:
x=GetValue()
could very well have been declared inside an include file that got
included via a namespace such as:
include GetValues.ew as GetStuff
Now in that previous line the user decided to skip the namespace prefix so
instead of writing:
x=GetStuff:GetValue()
the previous line was used instead.
This works perfectly well in Euphoria, and as far as i know this
is the way it's always going to work.
Now the default is to use GetValue() without a namespace, but
from my experiance this wouldnt be the greatest idea because we
not only want our program to work now, we want it to work after
we add something else too, so a warning would be great, and
an option to either use the prefix or not use the prefix would
be nice too.
Another situation to be careful about is...
Since new names will appear as the mashing is in progress, they will
have to be checked to make sure there is no other name exactly the same.
Since you wont know all 'till the end of the whole mash process, you'll
have to keep some reference to occurances so you can 'rename' a second
or even third/fourth time if need be. You probably thought about this
already though.
I'd be more than happy to test your program out fully once you think
you've got it to the point where it can handle namespace declares.
Take care,
Al
END PREVIOUS
REPLY
Hi Al,
I have printed out your caveats and will refer to them as I proceed. Thanks
for offering to test the code (great to have that in writing :^D ). I may
need a couple of programs plus their includes set from you too, or
recommendations on posted programs I can practice with. I need at least a
simple and a medium-complexity program to mash so I can see how various
namespace issues play out. I might even (coff) have to write some myself
as tests, but that is a bad idea because I don't really have a feel
for namespace yet. This request is sent also to anyone who can suggest
a highly-namespaced program of not too great complexity.
My preference/fantasy would be a duplicate-name-killer
program that would scan the known universe and annhillate all duplicate
names, for global items, to be run as part of an anti-virus program. It
might be memory-resident too, and a voice would moan "No, no, no!" in a
sepulchural voice when the user attempts it. On the other hand, it is
probably just an example of the gnarliness of the world outside the
theoretical neatness of the programming mind.
--Quark
END REPLY
8. Re: Store Includes
DB James wrote:
>
> Al Getz wrote:
> BEGIN PREVIOUS
> Hi again Quark,
>
> Hee hee, YOWIE i guess is a good word for it too as there's a little
> work involved as im sure you know :)
> I think it would be very worthwhile however.
>
> As far as your question goes, i can only see one area of caution:
>
> A function call such as:
> x=GetValue()
>
> could very well have been declared inside an include file that got
> included via a namespace such as:
>
> include GetValues.ew as GetStuff
>
> Now in that previous line the user decided to skip the namespace prefix so
> instead of writing:
>
> x=GetStuff:GetValue()
>
> the previous line was used instead.
>
> This works perfectly well in Euphoria, and as far as i know this
> is the way it's always going to work.
> Now the default is to use GetValue() without a namespace, but
> from my experiance this wouldnt be the greatest idea because we
> not only want our program to work now, we want it to work after
> we add something else too, so a warning would be great, and
> an option to either use the prefix or not use the prefix would
> be nice too.
>
>
> Another situation to be careful about is...
>
> Since new names will appear as the mashing is in progress, they will
> have to be checked to make sure there is no other name exactly the same.
> Since you wont know all 'till the end of the whole mash process, you'll
> have to keep some reference to occurances so you can 'rename' a second
> or even third/fourth time if need be. You probably thought about this
> already though.
>
>
> I'd be more than happy to test your program out fully once you think
> you've got it to the point where it can handle namespace declares.
>
>
> Take care,
> Al
> END PREVIOUS
>
> REPLY
> Hi Al,
>
> I have printed out your caveats and will refer to them as I proceed. Thanks
> for offering to test the code (great to have that in writing :^D ). I may
> need a couple of programs plus their includes set from you too, or
> recommendations on posted programs I can practice with. I need at least a
> simple and a medium-complexity program to mash so I can see how various
> namespace issues play out. I might even (coff) have to write some myself
> as tests, but that is a bad idea because I don't really have a feel
> for namespace yet. This request is sent also to anyone who can suggest
> a highly-namespaced program of not too great complexity.
>
> My preference/fantasy would be a duplicate-name-killer
> program that would scan the known universe and annhillate all duplicate
> names, for global items, to be run as part of an anti-virus program. It
> might be memory-resident too, and a voice would moan "No, no, no!" in a
> sepulchural voice when the user attempts it. On the other hand, it is
> probably just an example of the gnarliness of the world outside the
> theoretical neatness of the programming mind.
>
> --Quark
> END REPLY
>
Hi again Quark,
Actually the library i submitted called "WinClass" has quite a few
programs of varying sizes that all use namespaces. These include
examples using the namespace prefix for some calls and not using
it for other calls which i think would be a good test situation
for your software.
As soon as you get it working with even one of the smaller
program 'demos' i'd like to try it myself...please let me know
ASAP.
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
9. Re: Store Includes
- Posted by Pete Lomax <petelomax at blueyonder.co.uk>
Jul 21, 2005
-
Last edited Jul 22, 2005
>DB James wrote:
>> recommendations on posted programs I can practice with. I need at least a
>> simple and a medium-complexity program to mash so I can see how various
>> namespace issues play out. I might even (coff) have to write some myself
>> as tests, but that is a bad idea because I don't really have a feel
>> for namespace yet. This request is sent also to anyone who can suggest
>> a highly-namespaced program of not too great complexity.
When I wrote Posetf, I crafted ten include tests, inc0 to inc9, in the
test subfolder, some of which use an incN subfolder. Be warned that
some of these (especially the ones including from a subfolder) are
extensions to the RDS standard, so for your purposes if they don't
work on exw.exe then you can ignore them (if you get no error
messages, or anything, assume the test worked). Also bear in mind I
haven't looked at these for 8 months. You can find Posetf at:
http://palacebuilders.pwp.blueyonder.co.uk/posetf.htm
or
http://palacebuilders.pwp.blueyonder.co.uk/Z.ZIP
Regards,
Pete
10. Re: Store Includes
> > I have printed out your caveats and will refer to them as I proceed. Thanks
> > for offering to test the code (great to have that in writing :^D ). I may
> > need a couple of programs plus their includes set from you too, or
> > recommendations on posted programs I can practice with. I need at least a
> > simple and a medium-complexity program to mash so I can see how various
> > namespace issues play out. I might even (coff) have to write some myself
> > as tests, but that is a bad idea because I don't really have a feel
> > for namespace yet. This request is sent also to anyone who can suggest
> > a highly-namespaced program of not too great complexity.
> >
> > My preference/fantasy would be a duplicate-name-killer
> > program that would scan the known universe and annhillate all duplicate
> > names, for global items, to be run as part of an anti-virus program. It
> > might be memory-resident too, and a voice would moan "No, no, no!" in a
> > sepulchural voice when the user attempts it. On the other hand, it is
> > probably just an example of the gnarliness of the world outside the
> > theoretical neatness of the programming mind.
> >
> > --Quark
> > END REPLY
> >
>
> Hi again Quark,
>
> Actually the library i submitted called "WinClass" has quite a few
> programs of varying sizes that all use namespaces. These include
> examples using the namespace prefix for some calls and not using
> it for other calls which i think would be a good test situation
> for your software.
> As soon as you get it working with even one of the smaller
> program 'demos' i'd like to try it myself...please let me know
> ASAP.
>
>
> Take care,
> Al
>
> And, good luck with your Euphoria programming!
>
> My bumper sticker: "I brake for LED's"
>
Hello Al,
First, an aside: would it be a good idea to have all these ">" marks in
repies to replies to [repeat n times} have a number instead of the multiple
right angle brackets? Like:
4>Comment made a long time ago
3>A reply to the comment
2>An insightful comment about the reply comment
1>The latest quoted item
And ta-DA! the current comment. These proliferating angles keep messing up
the formatting that people try to use to make things clearer. My
one-fiftieth of a dollar's worth of an idea...
Thanks for the tip on WinClass. I've downloaded it and will use it for
testing. And I will let you know as soon as I have something for testing.
I am not at the moment sure how it will go. Ideally I'll have something
that will give a resulting program that will take little user tweaking to
work. We'll see. I keep thinking Mash.ex will have other uses or offshoots
as time goes on. My main thought now is to create a clean program to give to
people that has no junk hidden in libraries. Also, I just want to know
exactly what items my program does use. It might lead me to clean up my
act and write tight coherent libraries (dreaming here, I think).
Meanwhile I continue to buff what I have done in StoreInc.ex and its close
relative IncAll.ex. To somewhat repeat myself, the latter program does what
StoreInc.ex does, but it also produces AllFiles.txt with all includes
crammed into the same file as the original file chosen. The includes are
arranged properly so the dependencies work. An example from today's
efforts has produced a 1.6 Mb file from wxIDE.exw which has some namespace
stuff. I am daunted by the file size, but the computer and the program
don't seem to mind...
--Quark
11. Re: Store Includes
Pete Lomax wrote:
> <a
> href="http://palacebuilders.pwp.blueyonder.co.uk/posetf.htm">http://palacebuilders.pwp.blueyonder.co.uk/posetf.htm</a>
> or
> <a
> href="http://palacebuilders.pwp.blueyonder.co.uk/Z.ZIP">http://palacebuilders.pwp.blueyonder.co.uk/Z.ZIP</a>
>
> Regards,
> Pete
>
Hi Pete,
Thanks for the help. I've downloaded your work and will run it through the
mill and see what comes out.
A helping thought I've had is Robert probably found a simple way to deal with
namespace or he would have been reluctant to proceed. So maybe just thinking
about the problem will eventually result at a reasonably simple way of dealing
with it. From my current view, however, the thing seems strewn with pitfalls.
I just have to remember those stirring lines of verse: "The boy stood on the
burning deck, his face was white as snow, and everywhere the storm did vent,
his ship was sure to go."
--Quark
12. Re: Store Includes
Hi there Quark,
Yes sometimes the angle brackets are a little confusing, but i guess there
has to be some way to organize the replies and return replies etc. I
actually havent thought about that too much :)
Yes WinClass has lots of namespace prefixed references which should be
a very good test for a program that could mash a program correctly.
If the program runs after the mash then i guess everything got redone
correctly, and i'd really like to see this happen. I like to write
programs using that library but i have a feeling most people dont like
to use namespace prefixes (yet).
I have a feeling WinClass mashes will result in much smaller files than
1 or 2 megs, but i guess if someone includes lots of classes it can
grow larger and larger.
As far as the mechanics or dealing with namespaces, cant you connect the
namespace prefix to the target varname with an underscore or two?
MyClass:MyFunc()
becomes:
MyClass__MyFunc()
But i guess that only works if the user uses the same prefix in every file..
Well, i guess there's the filename possibility...
include MyIncFile.ew as MyClass
val=MyClass:GetValue()
becomes:
val=MyIncFile_MyClass_GetValue()
but then that kind of muddies up the clarity of using a namespace.
What about if you insist that the user ALWAYS uses the same namespace
prefix with the same file (good practice anyway), which allows the above to
become:
val=MyClass_GetValue()
which retains all the the simplicity and clarity of the original source.
Ah, maybe a switch to turn this 'feature' on or off ?
I find that the 'wordier' the names are the more easily the file can be read
and understood, especially several months later, but i guess there's a limit
to this. val=MyIncFile_MyClass_GetValue() would be stretching it a bit :)
Problem is, if you leave out "MyIncFile" then you've got to insist on
a correlation between filename and prefix name, and if you leave out "MyClass"
you might loose some of the author's original intent...unless they happened
to always do:
include MyClass.ew as MyClass
which i think will end up being rare.
I've found that short names work out good for prefixes, such as
include MyClass.ew as MC
That way when you go to use the 'object' like...
MC1=MC:Create()
vals=MC:GetValues(MC1)
the lines are shorter and the reading isnt that bad, unless you really want
super clarity:
include MyClass.ew as MyClass
MyClass1=MyClass:Create()
MyClass1Vals=MyClass:GetValues(MyClass1)
Now i guess there can be a problem if in one file the user declares:
include MyClass.ew as MC
and in another file the user declares:
include MyClass.ew as MyClass
In one file the user would type:
val=MC:GetValue()
and in the other:
val=MyClass:GetValue()
This makes it look like you'd have to insist that all the files were
included using the same namespace prefix (per filename). That is,
the dev'r would have to decide if they wanted to use "MC" or "MyClass".
Perhaps a message box to allow them to choose during run time?
Just some thoughts...
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
13. Re: Store Includes
Al Getz wrote:
>
> Hi there Quark,
>
> Yes sometimes the angle brackets are a little confusing, but i guess there
> has to be some way to organize the replies and return replies etc. I
> actually havent thought about that too much :)
>
> Yes WinClass has lots of namespace prefixed references which should be
> a very good test for a program that could mash a program correctly.
> If the program runs after the mash then i guess everything got redone
> correctly, and i'd really like to see this happen. I like to write
> programs using that library but i have a feeling most people dont like
> to use namespace prefixes (yet).
>
> I have a feeling WinClass mashes will result in much smaller files than
> 1 or 2 megs, but i guess if someone includes lots of classes it can
> grow larger and larger.
>
> As far as the mechanics or dealing with namespaces, cant you connect the
> namespace prefix to the target varname with an underscore or two?
>
> MyClass:MyFunc()
>
> becomes:
>
> MyClass__MyFunc()
>
> But i guess that only works if the user uses the same prefix in every file..
> Well, i guess there's the filename possibility...
>
> include MyIncFile.ew as MyClass
> val=MyClass:GetValue()
>
> becomes:
>
> val=MyIncFile_MyClass_GetValue()
>
> but then that kind of muddies up the clarity of using a namespace.
>
> What about if you insist that the user ALWAYS uses the same namespace
> prefix with the same file (good practice anyway), which allows the above to
> become:
>
> val=MyClass_GetValue()
>
> which retains all the the simplicity and clarity of the original source.
>
> Ah, maybe a switch to turn this 'feature' on or off ?
>
> I find that the 'wordier' the names are the more easily the file can be read
> and understood, especially several months later, but i guess there's a limit
> to this. val=MyIncFile_MyClass_GetValue() would be stretching it a bit :)
> Problem is, if you leave out "MyIncFile" then you've got to insist on
> a correlation between filename and prefix name, and if you leave out "MyClass"
> you might loose some of the author's original intent...unless they happened
> to always do:
>
> include MyClass.ew as MyClass
>
> which i think will end up being rare.
>
> I've found that short names work out good for prefixes, such as
>
> include MyClass.ew as MC
>
> That way when you go to use the 'object' like...
>
> MC1=MC:Create()
> vals=MC:GetValues(MC1)
>
> the lines are shorter and the reading isnt that bad, unless you really want
> super clarity:
>
> include MyClass.ew as MyClass
>
> MyClass1=MyClass:Create()
> MyClass1Vals=MyClass:GetValues(MyClass1)
>
>
> Now i guess there can be a problem if in one file the user declares:
>
> include MyClass.ew as MC
>
> and in another file the user declares:
>
> include MyClass.ew as MyClass
>
> In one file the user would type:
> val=MC:GetValue()
> and in the other:
> val=MyClass:GetValue()
>
> This makes it look like you'd have to insist that all the files were
> included using the same namespace prefix (per filename). That is,
> the dev'r would have to decide if they wanted to use "MC" or "MyClass".
> Perhaps a message box to allow them to choose during run time?
>
>
> Just some thoughts...
>
>
> Take care,
> Al
>
>
> And, good luck with your Euphoria programming!
>
> My bumper sticker: "I brake for LED's"
>
Hi Al,
I wanted to reply fairly quickly, but my thinking on this matter is under-
going considerable change and I haven't much to usefully add to the flow
yet. I am doing a lot of re-writing and the associated debugging and
am in some danger of getting bogged down. I'm going back to basics in
this project and moving forward again. I confess the namespace issue is
now looking like a massive solution in search of a justification. That is,
if namespace is really just a way of allowing duplicate names for different
items, it is hard to take it really seriously. Different things should
always deserve different names.
I know little about the origin of namespace issues (especially in other
languages than Eu), but I suspect it had its impetus from dealing with
object code and/or dll's from another language where one had to import terms
that may have been pre-empted by the language used by the programmer. In
such a case, there was an obvious need to provide an alias for the duplicate
term, because there was no access to the library -- that is, no way at all
to change the hard-coded term. This makes sense to me and gives a good
reason for an alias option. But where libraries are mere text, and can be
changed in moments, the namespace issue, to me, lacks real rational. I know
there have been strong feelings on this, but in my view, a majority of such
issues have more to do with beloved habits learned with other languages than
with true power of programming. Of course, there are many exceptions to
this, but it is worth asking: is this pet feature a big deal, or is it just
a cool thing I like?
I have printed out your reply to give thought to it. Meanwhile I am going
to proceed by killing all namespace references (I admit I'm happy to do
this) to see if it is a big deal after all. If, for example, there are just
a few duplicate items in even a huge program, then it is far easier just
to change the names and be done with it.
If, however, I become convinced there are real useful arguments for
namespace, then I'll see if I can figure a way to deal with it. To be
honest, if the rational is just preference, then to heck with it. So far,
it seems as if even the minor addition to Eu that namespace is, is like a
small wart on a pretty woman's face.
--Quark
14. Re: Store Includes
DB James wrote:
>
> Al Getz wrote:
> >
> > Hi there Quark,
> >
> > Yes sometimes the angle brackets are a little confusing, but i guess there
> > has to be some way to organize the replies and return replies etc. I
> > actually havent thought about that too much :)
> >
> > Yes WinClass has lots of namespace prefixed references which should be
> > a very good test for a program that could mash a program correctly.
> > If the program runs after the mash then i guess everything got redone
> > correctly, and i'd really like to see this happen. I like to write
> > programs using that library but i have a feeling most people dont like
> > to use namespace prefixes (yet).
> >
> > I have a feeling WinClass mashes will result in much smaller files than
> > 1 or 2 megs, but i guess if someone includes lots of classes it can
> > grow larger and larger.
> >
> > As far as the mechanics or dealing with namespaces, cant you connect the
> > namespace prefix to the target varname with an underscore or two?
> >
> > MyClass:MyFunc()
> >
> > becomes:
> >
> > MyClass__MyFunc()
> >
> > But i guess that only works if the user uses the same prefix in every file..
> > Well, i guess there's the filename possibility...
> >
> > include MyIncFile.ew as MyClass
> > val=MyClass:GetValue()
> >
> > becomes:
> >
> > val=MyIncFile_MyClass_GetValue()
> >
> > but then that kind of muddies up the clarity of using a namespace.
> >
> > What about if you insist that the user ALWAYS uses the same namespace
> > prefix with the same file (good practice anyway), which allows the above to
> > become:
> >
> > val=MyClass_GetValue()
> >
> > which retains all the the simplicity and clarity of the original source.
> >
> > Ah, maybe a switch to turn this 'feature' on or off ?
> >
> > I find that the 'wordier' the names are the more easily the file can be read
> > and understood, especially several months later, but i guess there's a limit
> > to this. val=MyIncFile_MyClass_GetValue() would be stretching it a bit :)
> > Problem is, if you leave out "MyIncFile" then you've got to insist on
> > a correlation between filename and prefix name, and if you leave out
> > "MyClass"
> > you might loose some of the author's original intent...unless they happened
> > to always do:
> >
> > include MyClass.ew as MyClass
> >
> > which i think will end up being rare.
> >
> > I've found that short names work out good for prefixes, such as
> >
> > include MyClass.ew as MC
> >
> > That way when you go to use the 'object' like...
> >
> > MC1=MC:Create()
> > vals=MC:GetValues(MC1)
> >
> > the lines are shorter and the reading isnt that bad, unless you really want
> > super clarity:
> >
> > include MyClass.ew as MyClass
> >
> > MyClass1=MyClass:Create()
> > MyClass1Vals=MyClass:GetValues(MyClass1)
> >
> >
> > Now i guess there can be a problem if in one file the user declares:
> >
> > include MyClass.ew as MC
> >
> > and in another file the user declares:
> >
> > include MyClass.ew as MyClass
> >
> > In one file the user would type:
> > val=MC:GetValue()
> > and in the other:
> > val=MyClass:GetValue()
> >
> > This makes it look like you'd have to insist that all the files were
> > included using the same namespace prefix (per filename). That is,
> > the dev'r would have to decide if they wanted to use "MC" or "MyClass".
> > Perhaps a message box to allow them to choose during run time?
> >
> >
> > Just some thoughts...
> >
> >
> > Take care,
> > Al
> >
> >
> > And, good luck with your Euphoria programming!
> >
> > My bumper sticker: "I brake for LED's"
> >
>
> Hi Al,
>
> I wanted to reply fairly quickly, but my thinking on this matter is under-
> going considerable change and I haven't much to usefully add to the flow
> yet. I am doing a lot of re-writing and the associated debugging and
> am in some danger of getting bogged down. I'm going back to basics in
> this project and moving forward again. I confess the namespace issue is
> now looking like a massive solution in search of a justification. That is,
> if namespace is really just a way of allowing duplicate names for different
<snip>
Hi Quark,
Well, i dont think it's really an issue to argue for or against
namespaces because this has been talked about years ago for days
on end and the best solution was agreed to be what is actually
present today. In my case, with my one particular library, the
namespace is used to declare a 'class' of a sort, somewhat similar
to a C++ class. This comes out working so wonderful and causes
a great organization of your code without doing anything extra,
and the readability increases to some extent too, because you dont
wade through a bunch of code looking at verbs first and nouns second
(like a speaking language most of the time). Rather, the nouns come
first and the verbs second...something that someone wont fully understand
until they've actually coded a few projects like this and then went
back to add and modify (maintain) things. Without it it can be like having
to look through EVERY brand of tire just to get to the car we want, when
it should be the other way around. Also, if it's used right, the 'class'
method can be a way of quickly changing your code and easily providing
new objects for use using the same techniques as any other 'class'.
This is what i call "Taking the good stuff about C++ and leaving the
bad stuff behind" :)
But enough with the namespace arguments, it is part of the language
and so people will use it. That doesnt mean your program has to support
this feature though :) If it seems to complicated then dont worry
about it...maybe i'll be able to modify your program to work with it
to some degree?
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
15. Re: Store Includes
Al Getz wrote:
> Hi Quark,
>
> Well, i dont think it's really an issue to argue for or against
> namespaces because this has been talked about years ago for days
> on end and the best solution was agreed to be what is actually
> present today. In my case, with my one particular library, the
> namespace is used to declare a 'class' of a sort, somewhat similar
> to a C++ class. This comes out working so wonderful and causes
> a great organization of your code without doing anything extra,
> and the readability increases to some extent too, because you dont
> wade through a bunch of code looking at verbs first and nouns second
> (like a speaking language most of the time). Rather, the nouns come
> first and the verbs second...something that someone wont fully understand
> until they've actually coded a few projects like this and then went
> back to add and modify (maintain) things. Without it it can be like having
> to look through EVERY brand of tire just to get to the car we want, when
> it should be the other way around. Also, if it's used right, the 'class'
> method can be a way of quickly changing your code and easily providing
> new objects for use using the same techniques as any other 'class'.
> This is what i call "Taking the good stuff about C++ and leaving the
> bad stuff behind" :)
> But enough with the namespace arguments, it is part of the language
> and so people will use it. That doesnt mean your program has to support
> this feature though :) If it seems to complicated then dont worry
> about it...maybe i'll be able to modify your program to work with it
> to some degree?
>
>
> Take care,
> Al
Hi Al,
I guess you've been hit with both the electronic and the biological versions
of virus and must be reeling a bit, so I particularly appreciate your sane
response. I missed the long debate on namespace, and admit I probably don't
see the whole issue.
As to the Mash.ex program, and IncAll.ex that sets up AllFiles.txt for it,
they are probably about done as far as version 0.01 is concerned. It works
now on the files I have tested and gives a single file with no items that
are not used. It reports on duplicate routines and types. I may keep its
ability to make a fuller report which shows items used and unused, with the
unused being deleted. On the files I've tested, Mash.ex mashes them down
to about 20 or 25% of the size of AllFiles.txt. This would vary, of course,
depending on the program and its includes.
When it proves decent enough for a test (soon, I think), I'll send the files
to you in mashed form for test runs. As to modifying them for namespace
issues -- that is fine with me. Great, if fact, as there might be more use
of Mash that way. Also, I suspect other possibilities may come out of this,
other than mashing.
--Quark
