TinTin++ Mud Client The TinTin++ message board

 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
TinTin++ Mud Client

Adding Scope - A Possible Solution

 
Post new topic   Reply to topic    The TinTin++ message board Forum Index -> Feature Requests
View previous topic :: View next topic  
Author Message
atraeyu



Joined: 12 Dec 2007
Posts: 165

PostPosted: Wed Feb 19, 2014 6:57 pm    Post subject: Adding Scope - A Possible Solution Reply with quote

One of the things I've found most troublesome with TinTin is the lack of scope.

It's caused me some insane heartache with debugging and forced me to use rediculous naming conventions to avoid collisions - and I still need to figure out a better way.

As an example, here's an excerpt from my module manager class:

Code:

#nop Load the specified module, if it exists.;
#alias {aMODLoad} {
    #nop %1 is the name of the module.;
    #var {vMODTempName} {%1};

    #if {&vMODModules[$vMODTempName] == 0} {
        #showme {<aef>Module Manager <faa>$vMODTempName is not a valid module name.};
    };
    #elseif {"$vMODModules[$vMODTempName][loaded]" == "true"} {
        #showme {<aef>Module Manager: <faa>$vMODTempName is already loaded.};
    };
    #else {
        #showme {<aef>Module Manager: <faa>Loading: $vMODTempName};
        #class $vMODTempName read {$vMODModules[$vMODTempName][path]};
        #var {vMODModules[$vMODTempName][loaded]} {true};
    };

    #nop Cleanup temporary data.;
    #unvar vMODTempName;
};



The names are horrific. Smile But I found out quickly that using vTEMPIndex as the variable name for my index variable both here and in a module being loaded/initialized caused the index in the above code to be overwritten and led to bugs that were extremely difficult to identify.

Since all configuration directives are global by default, I imagine changing the default behavior would be out of the question - it would break everyone's existing code.

But what about implimenting a new configuration directive such as:

Code:

#local


This could be implemented similar to the #all command, in that it could prefix any other command, like so:

Code:

#local #var {index} {null};
#local #alias {myalias} {#showme Do stuff};


Any configuration directives prefixed with the #local command, would have a scope local to where they were declared - such as in a class, alias, or function. They would be invisible outside that scope.

This would make writing code like this possible (without worrying about naming collisions and cleaning up temporary data):

Code:

#class modulemanager kill;
#class modulemanager open;

#nop public interface - provides an interface to the class locals.;
#alias {module load} {moduleLoad %1};

#nop internal data - invisible to everything outside of this class;
#local #list modules create;

#nop this is a local alias. it can be called by the global module load alias, but is invisible outside of the class.;
#local #alias {moduleLoad} {
    #nop These are alias local variables. They will be invisible to everything outside of this alias.;
    #local #var {name} {%1};
    #local #var {path} {%2};

    #if {&modules[$name] == 0} {
        #showme {$name is not a valid module name.};
    };
    #elseif {"$modules[$name][loaded]" == "true"} {
        #showme {$name is already loaded.};
    };
    #else {
        #showme {Loading: $name\.};
        #class $name read {$modules[path]};
        #var {$modules[$name][path]} {$path};
        #var {$modules[$name][loaded]} {true};
    };

    #nop No need to cleanup temporary data anymore - it's not visible outside of this function.;
};

#class modulemanager close;


... I would absolutely love this feature. But until then, I'll keep working on a better solution with what's available. Smile
Back to top
View user's profile Send private message AIM Address
Scandum
Site Admin


Joined: 03 Dec 2004
Posts: 3770

PostPosted: Wed Feb 19, 2014 8:49 pm    Post subject: Reply with quote

It can be an issue at times. Variables are currently tied to sessions, so it'd be some trouble to separate them into local / global. Not really something I want to mess with.

There's half finished / implemented infinite string support which I'm trying to find the motivation for to finish up. So that's kind of where I'm at. Coffee
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic   Reply to topic    The TinTin++ message board Forum Index -> Feature Requests All times are GMT - 5 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Get TinTin++ Mud Client at SourceForge.net. Fast, secure and Free Open Source software downloads Get TinTin++ Mud Client at SourceForge.net. Fast, secure and Free Open Source software downloads
TinTin++ Homepage

Powered by phpBB © 2001, 2002 phpBB Group