RE: [RC] Lucius tries to use namespace
irvm at ellijay.com wrote:
>
>
> Lucius, in all his subtlety, is just saying what anyone who has taken a
> close look at 'namespaces' must be thinking.
>
> I had hoped that Rob would come up with a brilliant, (and perhaps
> uexpected)
> solution to the namespace problem. He sometimes does that sort of thing.
> What we got instead was more like a band-aid for a broken leg -
> while it might be needed, it's also completely inadequate.
>
> The problem is not, however, as Lucius stated: that you must prefix each
>
> namespaced variable/function. That is a minor annoyance, and would have
> been even less of a problem if Rob had listened to the numerous
> suggestions
> that he implement something along the lines of Pascal's 'with .... do'
> statement.
>
> The real problem is that namespacing is braindead.
>
> Let's look at a real-life example:
> In GTK, there are many controls which have similarly but logically named
>
> functions, for example: get_text(). Some of these functions take
> different
> parameters than others.
>
> To write a program using GTK, I have a choice:
>
> Option 1:
> I can specifically 'include ... as ..." each individual GTK control from
> its
> own Eu include file. That makes 124 lines of "include ... as" at the
> top of each program for any program which uses more than a few
> controls. Get real - this entre post is only about 100 lines long.
> Do you really want that much prelude to each of your programs?
>
> Option 2:
> I could write a wrapper for all these includes, and just put a single
> line:
> "include wrapper"
> at the top of each new program. A much better solution, right?
>
> Wrong. **
> While in the wrapper, each include has its own identity
> (the name I chose when "including .. as"). For example:
> include entry.e as entry
> include textbox.e as textbox
>
> This eliminates name collisions inside the wrapper, because I can
> refer to "entry:set_text()" or "textbox:set_text()".
>
> But what happens when I try to access these functions from my main
> program (the one which just 'include(s) wrapper') ?
> I get an error message telling me that:
> A namespace qualifier is needed to resolve set_text.
> set_text is defined as a global symbol in:
> entry.e
> textbox.e
> textedit.e
> label.e
> button.e ....etc
>
> So Euphoria knows there are several versions of "set_text()" out there,
> and even which files they are found in, even though I did not
> specifically
> "include" ANY of those files in my main program. Cool.
>
> So I'll just qualify the function, right?
> entry:set_text("Hello World")
>
> Wrong again!
> entry has not been declared.
>
> How does Eu know where all these "set_text()" functions are located?
> It got that info from the "wrapper", where they _were_ included,
> obviously.
>
> ---------------
> Q: If Eu can pass on the names of included files, as
> well as the names of all the globals in those files, why can't it also
> pass on the namespace qualifiers given to those files?
>
> Ans: Braindead.
> ---------------
>
> OK, Rob will say namespacing wasn't designed for that purpose, but
> only to make it easier to include libraries written by other people.
> Perhaps he will explain how using a library from someone else
> differs from using the identical library written by oneself.
>
> ** note: I managed to work around that problem, but the solution sure
> didn't involve using namespaces. It would have been *much* simpler if
> proper namespacing had been implemented.
>
> Irv
>
>
<snip>
Hello again Irv,
I didnt have that much of a problem when i wrote the WinClass
Library, which depends highly on the use of namespaces for
naming its classes.
SetText() is an interesting example too, because there are lots
of those functions, in most of the classes.
To set the text for a single line edit control, you would type
SLEdit:SetText(ID,"Text 1")
but for a multiline edit control you would type
MLEdit:SetText(ID,"Text 2")
but these could be shortened to
SLE:SetText(ID,"Text 1")
and
MLE:SetText(ID,"Text 2")
if you use the shorter namespace names.
So you see it does in fact work out well.
If it didnt, i could have never have done it this way.
The only time a problem comes up is when you try to
include a library that incorporates other namespace
usage conventions.
The best conventions would probably be:
[1]
any file that comes with Euphoria never gets a namespace
(get.e, file.e, etc.)
any file you write yourself always gets a namespace
(DoThis.ew, DoThat.ew, etc)
This works out pretty well, except it's also nice to
include the Windows constants without a namespace also,
and a very few number of atoms that need to be global
to the whole program (such as the 'this' pointer).
--these two dont get namespace names:
include WConst.ew
include WM_Const.ew
Now a constant like
WS_OVERLAPPEDWINDOW
doesnt have to be prefixed.
Part of the reason i wrote that library is to get a feel for
what namespaces are all about and how they can be used.
I agree that there could be improvements, but it does
work right now to some degree.
Take care for now,
Al
|
Not Categorized, Please Help
|
|
