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