Zugg Software :: View topic

Posted: Mon Apr 28, 2008 11:49 pm

I've searched the predefined variable list in the hopes of finding one with the name of the currently running alias name in it, and no luck. Did I miss it or there is no such thing?
I was thinking of using such information as follows:

Posted: Tue Apr 29, 2008 12:40 am

Seems to me like it'd be much simpler just to put the code you want that alias to run into that alias rather than doing all that crazy indirection and hiding the code away somewhere.

Anyway, there's no way to get the name of the alias that's running by default. You could stick the name of the alias in a variable at the start of the alias if you need to know it later for some reason, but like I say, I can't see why you'd want to.

Posted: Tue Apr 29, 2008 1:18 am

Well Fang, if people had said that at the infancy of computer programming we would still be punching zeroes and ones into cardboards. There are many ways to do things and the language dictates how a program can be structured just as natural languages structure what people can think. There are cases for functions or (aliases in the case of zScript) where "self-awareness" can be useful. You didn't see a need for the type of code I showed in my post, and frankly at this moment, neither can I. But the fact that you can do it means that it can be used. I could come up with a script that would use that as a theme and I guarantee you that because of that scheme that script could do something that other scripts couldn't do, or couldn't do it as easily. For instance, you rightly suggest that sticking the name of the alias in a variable would do the trick. Having the interpreter stick the name of the alias in a variable would also do the trick and it would do it better because the script interpreter is faster, by definition, than the script itself. We could all, for instance, write a script that would extract the square root of a number, but isn't it nicer, easier, and faster that we can just use %sqrt()?

EDIT: I would settle for a native variable that tells me what alias called me. Which I guess is what I meant all along. Though either way would work.

Posted: Tue Apr 29, 2008 3:12 am

I really don't think this is necessary. Say you wanted a function that'd do two different things depending on whether it was called from alias "one" or alias "two".

#function dosomething($cmd,$alias) {#switch ($alias="one") {#say $cmd} ($alias="two") {#exec $cmd}}
#alias one {#call @dosomething("hello!","one")}
#alias two {#call @dosomething("hello!","two")}

This problem is complicated by the fact that you can have nested aliases, and aliases nested inside function calls. What if the command in the two alias above was to run the "one" alias? Which alias name would be passed to @dosomething in your example? It all seems very hassle-filled when all you need to do is

#alias one {#say "hello!"}
#alias two {#exec "hello!"}

Which is why I asked for an example where it's necessary or where it simplifies things. I don't think it's unreasonable to ask you to explain your proposal in more detail.

Posted: Tue Apr 29, 2008 4:09 am

OK, Fang. Picture this:
A table with areas. Each area has 1 or more portals associated with it.
A table with portals, each portal associated with an area.
From the above it is inferred that the mapping of the portal table to the map table can be many-to-1.
Now, the mapper invokes the correct portal for the area, that is, it generates the correct portal to obtain the shortest speedwalk. However, the portal that the mapper invokes is an alias. If you write a distinct script for each portal there is no problem, but that defeats the purpose of automation.
It is true that the portal processing script can be passed some indication of what the caller wants, but it is quite elegant, and quite common in many languages for the currently executing routine to know who the invoker is. To handle a many-to-one mapping this is paramount. One way or the other.
Now, since I am already handling the situation it is obvious that it can be done without my ideal of having a script know who the caller is. However, this is one of many applications. I am sure that if an %invoker native variable existed, people would come of with many ways to use it. For one thing, this would lead to the design and writing of metascripts.

EDIT: What amazes me is that there are arguments against something which is actually trivial to implement and which has much beneficial potential impact on script-writing.

Posted: Tue Apr 29, 2008 5:53 am

I don't think Fang's intent is to argue the point or your idea. I believe his intent is to see how or why it should/could be used. He merely stated reasons why he thinks implementing that would be unneccesary, and you pointed out reasons why it is. Arguments are highly separate from debates.

Back to the topic on hand, CMUD has a lot of functions that most average MUDders don't use or don't even know about. For instance, not too many people know about %session. Even fewer use it. How many care to use %grep? I use it when I'm logging a session and want to find a certain quote or line from my logs.

All in all, it is a nice idea. But only those serious about their scripts would probably use it. However, Zugg did say that THREAD isn't something a normal person would care about. I don't use it. Hell, I've still got to learn how to really incoporate RAISE and EVENTs work. Heh.

Charneus

Posted: Tue Apr 29, 2008 12:40 pm

In the past this is definitely something I would have used. When I wrote scripts I liked to put usage blocks in with the name of the script at the start. The thing is I'm the type of person who first calls a script fred or bert or anything silly until I come up with the proper name. This would have saved me from having to remember to go back into the script and change the name for the usage block.

Enchanter Joined: 05 Mar 2003 Posts: 593 Location: Canada

If was going to be implemented, then I think a variable that just gives the name of the invoker wouldn't really cut it.
What if the invoker isn't an alias but a function or a trigger.
To be somewhat useful the %invoker variable would probably have to reference an object like the %session variable does.
That way you could use it to get some specific information about your caller:
Of what type is the invoker trigger alias function or whatever,
Who invoked it and follow it upwards along the chain.
Any other info that could be used to determine exactly who invoked who.
There could be any number of executable units with that same name.
If its just a name string, there's no reason why that name couldn't /shouldn't be passed as an argument.

It would be great if zScript was more geared towards object oriented techniques, however...
If it were done when 'tis done, then 'twere well it were done well.

Posted: Tue Apr 29, 2008 11:46 pm

I was thinking along the same lines, Dharkael. Something along the usual format of invoker's name|invoker's type. In this case an object wouldn't be needed, IMHO, because #EXEC {%invoker} would work (if one wanted to do such thing). However, the idea of the object has more appeal because, as you pointed out, information about the caller could be extracted from it. The more information a routine has, the more precise it can be. The new object, though, would have to be a manufactured one rather than the COM-type object %session returns. Come to think of it, there are no objects, per se, in CMUD/ZMUD. So we are back to the string list format, which is the closest it comes to objects.

EDIT: Maybe CMUD 10.0 will be object-oriented!? Laughing

EDIT: It occurs to me that if functions were made to expose properties and methods(!), they would resemble the object-like entities in Javascript.

Wizard Joined: 22 Mar 2007 Posts: 2320

One difficulty I see with this idea is: what if the invoker is a trigger which doesn't have a short name?

Posted: Thu May 01, 2008 11:27 pm

I would think that anonymous triggers would return a null for %invoker, while named ones would return their names. Triggers are routinely named so that they can be objects of commands. If there is a need for a script to know that it has been invoked by a trigger, then the trigger would be tagged. The existence of the %invoker variable (or function) facilitates certain scripting methodologies, but like many other predefined schema in CMUD, it doesn't have to be used.