Globals and namespaces for Rev.

[Andre Garzia]

Ruslan,

you're trying to use globals and not conflict with other stacks right? 
that is the problem?

Well,  I made my own "addition" to our standard informal script 
variable name scheme.

Usually one naming a global will begin the var with "g"  and if it is 
an array will end the var in "A" like:

gMyGlobalArrayA

I just add the stack name to the thing, for example, my RevHTTP stacks 
got internal vars like

gRevHTTP_SessionDataA

it's not the most readable thing in the universe, but to a name like 
this to conflict with another stack would be very difficult.
Also, you can always check "globalNames" to see if there's a possible 
conflict.

If you're felling masoquist, you could use dynamically generated global 
names and create your own symbol table with custom props. This way 
you're beyond namespacing, you're actually recreating an engine 
feature. It's fun to reinvent the wheel sometimes, and for one 
researching some interpreter creation stuff in rev that might prove a 
nice exercise. Creating name spaces just for the sake of having them is 
not a good motive in my opnion, I think we need a problem to solve, if 
this problem can only be solved with the addition of name spaces, then, 
okay, we'll bugzilla the feature request and vote like hell but if 
you're just trying to add namespaces to solve simple var name conflict 
then, I think we're going overkill.

Cheers
andre



On Jun 12, 2005, at 5:04 PM, Ruslan Zasukhin wrote:

> On 6/12/05 9:38 PM, "Robert Brenstein" <rjb at robelko.com> wrote:
>
> Hi Robert,
>
> I have decide cc to list this.
>
>>> Yes I have see that point. Still on OO way, each stack must have own
>>> namespace. My global var should not conflict to other stack.
>>>
>>> And this is possible to do.
>>>
>>>     stack1::var1
>>>     stack2::var2
>>>
>>> You have the same full control on your project, but you just forget 
>>> about
>>> headache. Revolution CAN add this. And if I'd use Rev I have ask 
>>> this each
>>> day on their list :-)
>>
>> But actually, globals are used primarily to pass values between
>> different stacks. Your suggestion goes contrary to that.
>
> NO. where you see contrary ?!
>
> Namespace DO NOT prevent you read/write that variable,
> Just IF you know that var1 is in the stack1 namespace you need write
>
>     stack1::var1
>
> What problems?
> I do not see any problems.
>
> But now you get safe if TEAM developer several Rev stacks.
> You are 100% safe that developers will not conflict.
> Just NEVER. Just with ZERO efforts.
>
> As for me, this feature can be EASY and logically be added into Rev
> language.
>
>
>> Within a stack, you can use custom properties of the stack in lieu of
>> globals. Any object within stack can have their own custom
>> properties, which are like persistent variables attached to an
>> object. By choosing an option, you scope them so to speak. Custom
>> properties are really also global since any stack can get them
>> remotely but their names are scoped to the object they are in. And
>> they can simple variables or arrays (normally referred to as custom
>> property sets).
>>
>> In case of your examples, it is also possible to place all work
>> handlers in the card script and use script-local variables (see
>> "local" keyword), which are static variables but scoped to that
>> script object only.
>
> Robert, it seems you think that NameSpace add scope.
> And you cannot access vars in the scope.
>
> Again no. Namespace DO NOT add scope.
> This is where its beauty.
>
>
> -- 
> Best regards,
>
> Ruslan Zasukhin
> VP Engineering and New Technology
> Paradigma Software, Inc
>
> Valentina - Joining Worlds of Information
> http://www.paradigmasoft.com
>
> [I feel the need: the need for speed]
>
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
>
-- 
Andre Alves Garzia ð 2004
Soap Dog Studios - BRAZIL
http://studio.soapdog.org