#81222 - 2002-09-06 04:04 PM
RFI: '.' dots in variable names
|
Sealeopard
KiX Master
Registered: 2001-04-25
Posts: 11164
Loc: Boston, MA, USA
|
Request for Implementation:
As stated in the manual, variables cannot contain a period '.', however, the period is valid for function names. This leads to an inconsistency since it is valid to create a function Class.Function() and call this function from KiXtart. However, this function cannot return a result since the variable $Class.Function is not a valid variable name.
I therefore propose to allow the period as part of a variable name in order to facilitate pseudo-object-oriented functions.
Alternatively, if it is impossible to implement, the functions names must not be allowed to contain periods in order to achieve naming consistency.
Desired implementation:
code:
$hours=Time.GetHours(@TIME)
function Time.GetHours($time) Dim $splittime
$splittime = split($time,':')
$Time.GetHours = $splittime[0] endfunction
This implementation would also enable KiXtart to support some kind of CLASS structure further down the development road, e.g. mimicking the Visual Basic class structures. [ 06. September 2002, 16:05: Message edited by: sealeopard ]
_________________________
There are two types of vessels, submarines and targets.
|
Top
|
|
|
|
#81223 - 2002-09-06 04:17 PM
Re: RFI: '.' dots in variable names
|
Chris S.
MM club member
Registered: 2002-03-18
Posts: 2368
Loc: Earth
|
If .'s are allowed as variable names, then how would KiX be able to interpret a class call versus a variable call?
Something as simple as...
code:
$FORM.CAPTION = "My Title"
...may get broken.
|
Top
|
|
|
|
#81225 - 2002-09-06 04:36 PM
Re: RFI: '.' dots in variable names
|
Shawn
Administrator
Registered: 1999-08-13
Posts: 8611
|
My vote - drop support for periods in function names (fix the inconsistency) ... but allow support for "functions-within-functions" ... imho - this would go a long way in furthering the OO cause.
Maybe with a structure like this (just green-lighting here):
code:
class Adder(constructor $parms...)
dim $n1,$n2 function SetN1($n) $n1 = $n endfunction function SetN2($n) $n2 = $n endfunction
function Add() $Add = $n1 + $n2 endfunction endclass
then you could instantiate and use the object, just like a COM object. The periods in function names would now refer to a function within the class.
code:
$Adder = Adder() $Adder.SetN1(2) $Adder.SetN2(2) $Answer = $Adder.Add()
one can always create functions to set and get (mimmic) properties (SetN1/GetN1) ... thats how things normally work under the covers anyways (in COM) ... [ 06. September 2002, 16:48: Message edited by: Shawn ]
|
Top
|
|
|
|
#81232 - 2002-09-06 08:11 PM
Re: RFI: '.' dots in variable names
|
kholm
Korg Regular
Registered: 2000-06-19
Posts: 714
Loc: Randers, Denmark
|
Suggestion(s), add's to the brainstorming
How about continnuing to let the the '.' be allowed in function names, and let the functions reference its returnvalue as the part after the '.' ?
Function name: Time.GetHours Internal reference: $GetHours
Jens's example could then look like this:
code:
$hours=Time.GetHours(@TIME) function Time.GetHours($time) Dim $splittime $splittime = split($time,':') $GetHours = $splittime[0] endfunction
If this was allowed and all scripts was following this syntax when dealing with a 'class' it might be easier to read other peoples scripts.
But this is just cosmetic, you migth as well make your own function name convention, like: All function names starting with $tm has to do with time, the script would then be:
code:
$hours=tmGetHours(@TIME) function tmGetHours($time) Dim $splittime $splittime = split($time,':') $tmGetHours = $splittime[0] endfunction
This would work with the current version of KiX
- A second suggestion could be to let the function reference itself as me (new reserved word), the function could then be coded as:
code:
$hours=tmGetHours(@TIME) function tmGetHours($time) Dim $splittime $splittime = split($time,':') me = $splittime[0] endfunction
function name would then be irrelevant, ofcourse KiX should still support $FunctionName as internal reference.
-Erik
ps. I like the idea of allowing functions inside functions, sort of a function only 'alive' when the parrent is active. What about functions inside functions inside functions ..................
|
Top
|
|
|
|
#81234 - 2002-09-06 08:19 PM
Re: RFI: '.' dots in variable names
|
Howard Bullock
KiX Supporter
Registered: 2000-09-15
Posts: 5809
Loc: Harrisburg, PA USA
|
If I would define a function within a function (or Class), Then why couldn't I refer to variables as $Class.Varname even if not currently in the parent function/class definition?
Further more I may have a Date function/class library with various discreet date functions. Shouldn't I be able to Date.DayOfWeek(@date) for example?
|
Top
|
|
|
|
#81237 - 2002-09-06 09:58 PM
Re: RFI: '.' dots in variable names
|
Howard Bullock
KiX Supporter
Registered: 2000-09-15
Posts: 5809
Loc: Harrisburg, PA USA
|
I guess I'm a little confused. I made a similar request/comment in another thread ( Should UDF collections be allowed) which is where I thought this "." in variables started.
I think that if a function within a class or package executes that we should be able to have persistent variables of the Class or package which could be referenced as $Class.var1 or $Package.Var1.
I haven't had much time lately to read all the post in depth (paycheck type work). Is this not what is being discussed?
|
Top
|
|
|
|
#81238 - 2002-09-06 10:31 PM
Re: RFI: '.' dots in variable names
|
kholm
Korg Regular
Registered: 2000-06-19
Posts: 714
Loc: Randers, Denmark
|
YES, Almost same discussion as in: Should UDF collections be allowed
AND almost the same partisipants.
Maybe we should summarize these discussions to a post in the suggestions (wish) forum ?
Like Shawn says: It never hurts to dream wha ? (wha ? being the danish version of eh ? in this situation)
|
Top
|
|
|
|
Moderator: Lonkero, ShaneEP, Jochen, Radimus, Glenn Barnas, Allen, Ruud van Velsen, Mart
|
1 registered
(Allen)
and 457 anonymous users online.
|
|
|