UnLIBRARY command

  • This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.
May 20, 2008
424
2
#3
Wildcards with /D are fine if you can guarantee locals do not conflict with globals. But, I would find requiring a prefix for everything to be quite the nuisance. For me, I would not likely need an UnLibrary if setlocal/endlocal covered that set as I could then do
Code:
setlocal
library /u /r %0
...
endlocal
Personally, I would prefer this support before the new command, though both have their uses.
 
#4
It'll be interesting to see how library functions are used and how they evolve. They are a lot like aliases already. It they're made more like aliases (UNLIBRARY /R file, global/local, SETLOCAL, support from SHRALIAS) they will be nearly identical, with the only differences being the ease of making multi-line ones.
 
May 20, 2008
424
2
#5
I kind of view them that way already, as an easier way of doing multi-line aliases. I don't view them as functions as all of my functions return a value. Library functions are more like aliases in that they are commands that do not return a value. The description wording is a bit confusing this way. Further, since my start BTM starts shralias if not running and loads an alias file, it was almost the same functionality to me as Library. The primary difference of library to me was the missing setlocal/endlocal support and being able to edit/reload a global set across sessions.
 
May 20, 2008
424
2
#8
It's the pedant in me triggered by my programming background where functions have returned values and procedures or subroutines do not. In C/C++/C#, that would be the difference between void and non-void return values. In VB, that would be the difference between SUB and FUNCTION. I'm also thinking of how the FUNCTION command in TCC is used. In the example above, test doesn't actually return a string. Instead, the subroutine is setting a value that can later be checked. If the above were an actual function, doing echo %@test[] would be valid and not produce an error.

I often use the @echo combined with @execstr to have some of my aliases reusable as functions. My function file would have these defined as func=%@execstr[alias %1] so I could directly use the result of calling the alias within an expression or comparison. But, this doesn't make the original alias itself a function. With a FUNCTION defined function, you can echo %@func[] or if %@func[] GT 0 to directly get/use the returned value. With a LIBRARY defined function, you cannot use the resultant (singular?) value directly. You would need to wrap it in an actual function to retrieve that 'return' value before it could be used. Thus, doing echo %@libfunc[] would fail while doing echo %@execstr[libfunc] would work. But, as I said at the opening of this post, this is just pedantry on my part.

Along this semantic/pedantic vein, this gives me the idea of method, where the function, procedure, or subroutine is internal to a class or, in this case, the file. That may lead to defining library methods as
Code:
library.method {
   ...
}
That would then allow for the prefix usage of LIBRARY /D library.* to remove all methods defined in that file. This then has me thinking of combining array variables with library files to simulate C++ style classes in BTM language. In addition to containing the class member variables, the array could also contain the vtable of the related internal methods. But, this gets into a whole other topic.
 
#9
Library functions are, like aliases, akin to commands. You have to wrap them in something to get a return value. Though it hasn't been mentioned, you can use @EXEC[] for that.
Code:
g:\tc22\library> library /f kk
kk {
set s=%@eval[%[$]]
quit %s
}

g:\tc22\library> echo %@exec[kk 3 + 5]
8
 
Oct 18, 2009
109
4
#10
I agree that there should be a standard way to return a value. As I wrote in the original suggestion discussion about adding a LIBRARY command, there is always a problem with workarounds because different people will implement different workarounds.

There are some related issues, such as TCC user-defined functions use the recognizable syntax %@FunctionName[]

Perhaps a switch could be added to the FUNCTION command, maybe /U for "user library" or /V for "variable name", since /L is already used.

Something like:

A LIBRARY contains
Christmas{
Echo Merry Christmas

Set ReturnVariableName=December 25th
Set RussianOrthodoxXmas=January 12th
}

FUNCTION /V=ReturnVariableName XMas=Christmas

FUNCTION /V=RussianOrthodoxXmas ROXMas=Christmas

echo %@XMas[]
December 25th

echo %@ROXmas[]
January 12th

That would have the benefit that you could have multiple FUNCTIONS use the same LIBRARY function. For instance, you might have a Library STATE function that sets

Set State_uc=ALASKA
Set State_mc=Alaska
Set State_abbrv=AK

FUNCTION /V=State_uc STATE_UC= STATE Alaska
FUNCTION /V=State_mc STATE_PROPER= STATE Alaska
FUNCTION /V=State_abbrv STATE_USPS_ABBRV= STATE Alaska