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
|
Not Categorized, Please Help
|
|
