Idea for NameSpace-problem
There is this idea I already have for a couple of years and it would sove
the name space problem, althrough I figured that it would be very
impracticle for performace, because of the advanced management that has to
be done.. i got this idea, finding a way to -context sensitive- program.
Here it goes:
- An item is a combination of a two procedures and a function. It can be
sent ONE value and receive ONE value. An variable in Euphoria works the same
way: you initialize it with a value (first procedure), you set/sent a value
(second procedure) and you read/receive a value(the only function). Only
with such variables you can be sure when you set it to, for example 100, it
will also return 100. Off course this depends on the purpose of an item.
- A program is also an item, the first time the program starts the
init-procedure is called, then when for example a second document is opened
the set-procedure is called. (Like DDE in windows does).The init-procedure
gets the command line as its value. the set-procedure gets the filename in
this example and the gets-function returns a status value (like "abort(65)"
does). Ussually the init procedure doesn't do much, and the set procedure is
the real program, however there are situations where you a different
procedure for another instance of a program is a real advantage.
- The program item is the parent item. All other items are his direct
children.
- These children can make either brothers (items on their own level) or
childrens.
- Childrens are completely hidden from their aunts,uncles and grandparents.
They can not be called by them, nor call them themselves. They can only have
contact through the parent. They 'filter' / 'passthrough' everything. It is
only available so can make sure no one else has acces to those items. (the
performance will also be a bit more, with children items)
- The item is refered to by the name it is declared by. Within a routine no
other item is visible, they all HAVE to be declared before you can use them.
This gives you a nice lookup table of which items you mess around with.
- The name can be a short and cryptic one, that may be interpretered in many
ways. For
example, it could be called 'text'
- There are two possible ways of declaration, one called adopting and
creating.
- When you adopt an item, you only create a local reference. It is not an
instance nor a clone or something. When you set an item to a certain value
this value is read by all other item that have adopted him. You can consider
this the same as globals in Euphoria, only you have to specify which globals
you want to have acces to.
- All items can be adopted. So any item can be changed. All this however
within one parent. Which is the case with the program-item. DOS can not
acces any item except the program-item. All other items are his -direct
childeren if you think in tree-systems. However remember that the
program-item doesn't have to be the one to create the items, they could also
have been created by sisters and brothers.
- So you either adopt an item (only a brother item BTW) to give yourself
acces to that item or you create one. When you create an item it is
available to all your brothers and sisters. This creating is a dynamic
thing, it occurs. It is not a declaration like adopting is. The
adopting-declaration of an item that does not exist either gives an error,
or is pretended to be some other item. This means, within the declareration
you can specify second, third, fourth, etc. items that the system should try
to adopt when the preceeding item was unavailable. Often you will find
yourself putting a default value here (a value is also an item, a clone of
the atom or sequence item, which provide the routines to initialize, store
and lookup the value) which can be overridden by a custom setting (item
thus) IF available.
- Together with an item is saved the path it took to get there. The path is
list of items. The path will be the path of the item that had adopted you
with the name of that item appended. This path is used when we get to
naming conflicts. The item 'text' occurs, for example, three times. With
three different paths, then it is a simple alphabeticall comparisation,
which 'text' we mean. We start at the beginning and whose path is more like
the path of the item adopting, that item is the one that gets adopted.
However in the declaration of that adopting you could also specify a piece
of the path, so you can also acces items out of your -context-. Note that
the path lookup and generation occurs only during the decleration of the
item. Which item created it is not important. However there will be
situation where more items are in context. Now we open up our box of tricks,
and execute a statement using a value of that item, for every item that is
available. So an ==> text = text & '\n' <== would then apply to all items
in context. (that match equally well to the pieces of path used at the
decleration). Also I would like to notice that the pieces of path in the
decleration can contain many wildcards, like 'NOT' and 'OR' so we can
specify even better which items do match our selection and which don't.
- During the creation we also give an value to the item, this value is
passed as the ONLY argument to the initialization procedure. So an item,
with the routines of an atom, has to be passed its initialization value
during creation. Why have this initialization procedure ? Cause we can
clone, and actually that is the only way to make an item. As a clone of a
different item. Standard, the items atom, sequence and integer are
available. The item program also. Creating a clone of this, enable
program-in-program. Only within the program-item you could during
development create a new -fresh- item. Later on you could only clone those
items. You could for example have a window item, which you initialize with
the name of the window. The window item's initialization procedure creates a
bunch of new items, called height, width, top, left, backgroundcolor, etc.
Where the window item's set and get routines automatically adopt them. And
there path is thus very close to the item that cloned the window item.
- The selection of the item, and the initialization argument are on one line
together with spaces. So an item could just use the argument given as a path
to one of his children, example ==> system users Ralf MY_PASSWORD secret1
text <== 'Ralf' is the last available item at this point, it will pass
"MY_PASSWORD secret1 text" to the item Ralf, which then uses that argument
to select which child he wants to adopt. This way we do have acces to
private items, but the parents item has to pass it through and can thus
filter it. Also the item that is adopting may be unaware of the security at
all. Since if it was a brother item, it would have worked either.
Well, that was mine idea, I hope I haven't bored or confused ya too much. If
there is any part you do not understand I'll try to redo that piece of
explenation. It would solve both the naming convention and the context
sensitive programming problems, wouldn't it ?
Ralf Nieuwenhuijsen
nieuwen at xs4all.nl
ICQ:9389920
|
Not Categorized, Please Help
|
|
