| Howard Bullock |
| (KiX Supporter) |
| 2005-04-08 11:17 PM |
|
concept of namespace?
|
We already have a DIM that can scope variable explicitly. By default any instantiated variable is "Global" in scope. Functions are are Global.
What is missing is a way to maintain and address those specially defined variables that are currently out of scope by namespace or package. We could scope functions in different packages or namespaces.
Maybe...
@scriptname:$A or other similar convention
or an explicit KiXtart command that defines a namespace.
package Myfunctions
function A()...Endfunction
function B()...Endfunction
Package OtherFunctions
function A()...Endfunction
If this construct was established then were could have functions and variable by the same name but stored in different scripts or sections of a script and called independently of each other.
ShawnsScript:functionA()
MyFunctions:functionA()
Maintaining a function library would be greatly enhanced.
| Sealeopard |
| (KiX Master) |
| 2005-04-09 06:19 PM |
|
|
Re: concept of namespace?
|
Reminds me of the overload abilities in various languages.
I think one way to enable this would be to allow for the decimal point in function names. This would eable us to create pseudo-object-oriented functions.
| Howard Bullock |
| (KiX Supporter) |
| 2005-04-12 08:26 PM |
|
|
|
Re: concept of namespace?
|
I thought this would generate a few more responses than just one...
| Kdyer |
| (KiX Supporter) |
| 2005-04-12 08:54 PM |
|
Re: concept of namespace?
|
The only benefit I can see with this is testing variations of functions. Maybe I am not seeing the "whole picture?"
Kent
Richard H.
|
| (KiX Supporter) |
| 2005-04-13 10:56 AM |
|
Re: concept of namespace?
|
A file scope for variables would be *very* useful, primarily for declaring globals that are only visible to functions defined in the file.
I adopt a variable naming convention that avoids the possibiltiy of name clashes of global variables or functions, but it would be nice to protect these as a feature rather than having to type/remember the long names that I currently use.
While we are talking about scope, I'm still very keen to see static variables, at least for function scopes. Static variables are variables that have a local scope, but are not destroyed on exit from the scope (Function / If..EndIf ...) so the variable and it's value is present when the scope is next entered.
| Howard Bullock |
| (KiX Supporter) |
| 2005-04-13 07:57 PM |
|
|
|
Re: concept of namespace?
|
If this namespace notion would be implemented, I think you could store your static vars there.
Code:
package NetworkLib
dim $counter
function A($a, $b)
dim $counter
for = $counter = 0 + NetworkLib::$counter to 5 + NetworkLib::$counter
;do stuff
next
NetworkLib::$counter = $counter
endfunction
package Main
;more code
NetworkLib::A($foo,$bar)
;print last record processed
? "the next record to process is record number: " + NetworkLib::$counter
This probably is not what you are looking for but I think it is better than globals.
| Howard Bullock |
| (KiX Supporter) |
| 2005-04-13 08:13 PM |
|
|
|
Re: concept of namespace?
|
As far as "file scope" if you 'Dim' a var at the beginning of a script "A" and call that script from script "B". Script "B" will not be able to see those script "A" vars because they are out of scope. Richard, is this type of action what you defined as "file scope"?
Test script for scopiing. Execute test.kic which calls test2.kix.
Code:
Break on
Global $TestA
$TestA="a"
Dim $TestE
$TestE = "e"
Call "test2.kix"
? "in test TestA ="+$TestA
? "in test Test2B="+$Test2B
? "in test Test2C="+$Test2C
? "in test Test2D="+$Test2D
? "in test TestE ="+$TestE
Code:
Break ON
Dim $Test2B
$Test2B = "b"
Global $Test2D
$Test2D = 2
if $Test2B="b"
Dim $Test2C
$Test2C="c"
endif
? "in test2 TestA ="+$TestA
? "in test2 Test2B="+$Test2B
? "in test2 Test2C="+$Test2C
? "in test2 Test2D="+$Test2D
? "in test2 TestE ="+$TestE
?
|
Richard H.
|
| (KiX Supporter) |
| 2005-04-14 10:18 AM |
|
Re: concept of namespace?
|
Quote:
As far as "file scope" if you 'Dim' a var at the beginning of a script "A" and call that script from script "B". Script "B" will not be able to see those script "A" vars because they are out of scope. Richard, is this type of action what you defined as "file scope"?
Not quite. You have declared a local variable, so it is not visible within functions defined in the same file.
Consider a library where you want constants or variables which are visible to functions and code within the library but not outside the file scope. The constants or variables have to be global to be visible within the function. If they are global then they are also visible outside the file scope, which is not what you want. You will also get a clash with an already defined global of the same name.
Namespaces are pretty close to doing the job, as a "Global" variable restricted to a namespace would effectively be a static variable in the namespace scope.
For the sake of sanity I don't think namespaces should be inherited, as they'd get very nasty very quickly.
| Sluice |
| (Fresh Scripter) |
| 2005-05-12 03:36 PM |
|
Re: concept of namespace?
|
Is there any mileage in the idea of being able to drill down to a local constant or variable within a function/sub within a library, or is that going too far? This might allow the script to grab a variable from within a remote function and use it or modify it locally. I'm not sure how this might be used, or whether it's taking object programming too far.
|
Richard H.
|
| (KiX Supporter) |
| 2005-05-12 04:06 PM |
|
Re: concept of namespace?
|
Quote:
Is there any mileage in the idea of being able to drill down to a local constant or variable within a function/sub within a library, or is that going too far? This might allow the script to grab a variable from within a remote function and use it or modify it locally. I'm not sure how this might be used, or whether it's taking object programming too far.
It's actually the complete reverse of object programming
The idea of an object is that the innards (code, data) is absolutely private and untouchable. The object might expose data as properties, but they are abstracts of what the real data is in the object.
Variables are not persistent - when a function exits they are destroyed so there is nothing to access or change.
If you can think of a useful application of accessing private function data that can't be met by other methods then post again. There's no point in adding functionality which will never be used
