Upon further reflection about the situation in Rev (as opposed to
languages that are really compiled, and execute from the start of the
program each time a change is made), I take your point. In Pascal, the
program/compiler must re-create each global each time the program is
run. In Rev, the
On Aug 2, 2005, at 6:13 PM, Richard Gaskin wrote:
In any language I've worked with, you declare a global and it stays
in memory until you delete it or quit the program.
I don't know of any language that deletes globals automatically
based on whether the app closes or opens files from disk.
Jon wrote:
I agree: it is unfortunate that the original language designers used the
term "global" to mean "persistent global". Had they separated the
concept of scope from the concept of variable duration/lifetime, the
language would have been equally powerful while being easier to understand.
I agree: it is unfortunate that the original language designers used the
term "global" to mean "persistent global". Had they separated the
concept of scope from the concept of variable duration/lifetime, the
language would have been equally powerful while being easier to understand.
Jon
Mar
Hypertalk, as I understood it from the beginning, was to be a free-form
style of programming that allowed interacting with many stacks, even
hundreds on multiple drives and computers. One major concept was the
navigation to prev>next>recent>push card>pop card. All this could involve
'jumping' to
I agree (with everybody), of course.
But it is true that until this thread came up I didn't think to look
in the Variable Watcher for signs of this. There were a couple of
globals that I had declared at an earlier experimental stage of
development of this project, still hanging around witho
Hi all,
I was very busy and did not follow accurately this thread.
I don't speak English very well but I know what global means: global
means global :-)
If you can empty a global, delete it from memory when needed, where
is the problem?
You can use good scripting conventions to be sure that l
Mark Wieder wrote:
Jacque-
Tuesday, August 2, 2005, 8:07:41 AM, you wrote:
Globals are necessary when one has a suite of stacks that must interact
as a unit. One very common example is a "find" handler. Assume a number
of data stacks, each a clone of the others. A handler asks what you want
t
Mark Wieder wrote:
Jacque-
Tuesday, August 2, 2005, 8:07:41 AM, you wrote:
Globals are necessary when one has a suite of stacks that must interact
as a unit. One very common example is a "find" handler. Assume a number
of data stacks, each a clone of the others. A handler asks what you want
t
Jacque-
Tuesday, August 2, 2005, 8:07:41 AM, you wrote:
> Globals are necessary when one has a suite of stacks that must interact
> as a unit. One very common example is a "find" handler. Assume a number
> of data stacks, each a clone of the others. A handler asks what you want
> to find and puts
xbury-
Monday, August 1, 2005, 11:48:56 PM, you wrote:
> Seems like a shoot-yourself-in-your-own foot script to me ;)
It is indeed. I'm quite aware of how to get in trouble using globals
. What I was looking for was an example of why semi-persistent
globals (sticky only during the current sessio
Chipp-
Tuesday, August 2, 2005, 12:07:24 AM, you wrote:
> I have a splashscreen stack which manages updates via my own MagicCarpet
> Auto-update application architecture. It creates a global from a
> download URL prefs file for the domain where the stack and all the
> plugins reside, then downl
Mark Wieder wrote:
And I still can't imagine a scenario in which you would want a global
left over from a previous stack *only for that session*. I'll warrant
that I may still be missing something VERY basic, but it still makes
no sense to me.
Globals are necessary when one has a suite of stac
it's not different. The global is persistent until you delete it.
So if you delete your global and rerun your script (as you would recompile
in other langs),
the global wont show up again.
I thought i had demonstrated that with my script in the little mail
following the question yesterday...
"In other languages, if you removed all references to a global and
recompiled, of course it would disappear...? "
Exactly! This is SO counterintuitive, no matter how useful it might be
I NEVER would have even considered that the language might behave in
this way. Another issue for the Intro
Ken Norris wrote:
At the risk of repeating myself, again, you just need to be aware of how
it works, that's all. Whatever Rev thing is running retains the globals
declared within it until it is closed.
This convention was established in 1987 by the inventors of the root
dialect, HyperTalk. G
Sure,
here's a good example of exactly what you're talking about.
I have a splashscreen stack which manages updates via my own MagicCarpet
Auto-update application architecture. It creates a global from a
download URL prefs file for the domain where the stack and all the
plugins reside, then d
Mark,
globals are best used as "environment" variables. Not as persistent
storage.
Your example shows that if stack b opens and fails to work with a global,
you
didn't set a pre-requisite (nor a check) for xyz's conformity... that's
asking for
trouble.
If stack B had this check, it could then
On Aug 1, 2005, at 9:52 PM, [EMAIL PROTECTED]
wrote:
Date: Mon, 1 Aug 2005 18:35:30 -0700
From: Mark Wieder <[EMAIL PROTECTED]>
Subject: Re: global problems
Ken-
Monday, August 1, 2005, 5:47:01 PM, you wrote:
(snip)
Globals are for what they say they are. A global declared
Chipp-
Monday, August 1, 2005, 6:46:33 PM, you wrote:
> Yep, I think you are missing something VERY basic.
> Globals are just that, they exist forever until you explicitly delete
> them. That's how they've always worked in all Xtalks I've ever used.
> You of course have a choice whether to use
Brian-
Monday, August 1, 2005, 6:56:19 PM, you wrote:
> For me, the rationale is simple: globals are the ONLY way to have data
> which is _not_ stack specific. As such, closing or modifying a stack
> should never delete global data.
I still don't get this. Can you give me an example of something
Global properties do!
For me, the rationale is simple: globals are the ONLY way to have data
which is _not_ stack specific. As such, closing or modifying a stack
should never delete global data.
Perhaps what you're really looking for is a stack-level local variable?
I'm thinking the seeming
Yep, I think you are missing something VERY basic.
Globals are just that, they exist forever until you explicitly delete
them. That's how they've always worked in all Xtalks I've ever used.
You of course have a choice whether to use them or not. I, enjoy using
them as I find they have many 'u
Ken-
Monday, August 1, 2005, 5:47:01 PM, you wrote:
>> Constants
>> certainly don't.
> Well, why would they? They're opposite things to variables.
Right... well, the point I was trying to make is that there's
*nothing* else that has this persistence. Maybe I chose a bad example.
> Globals are
Actually, to delete a global from the message box you need:
global ; delete global
I guess it is the same as having to refer to the global (initialise
it?) in a script before using it.
At 7:36 PM -0500 1/8/05, [EMAIL PROTECTED] wrote:
Now hold on a minute; I did remember a time a version ba
Hi Mark,
Date: Mon, 1 Aug 2005 11:00:47 -0700
From: Mark Wieder <[EMAIL PROTECTED]>
Subject: Re: global problems
Just a little note from"the other" Ken (or one of them) --
Hmmm... "delete global"... you're right - I use globals so
infrequently that it woul
Now hold on a minute; I did remember a time a version back when I set
a global when I should have set a local, and the global wouldn't go
away, I couldn't recreate as a local, even though I used 'delete'
from the msg box. It insisted on being a global. I had to quite rev
to continue...
sqb
Ken-
Monday, August 1, 2005, 8:56:23 AM, you wrote:
> There are only two times when globals are completely removed - when the
> interpreter quits, or when you explicitly delete globals with the syntax
> above. Simply removing the declarative line of code doesn't "tell" Rev to do
> anything other
On 8/1/05 2:28 AM, "Mark Wieder" <[EMAIL PROTECTED]> wrote:
> Global variables are persistent in memory, even when they've been
> purged. Once you have declared a global variable, even if you have
> deleted the line of code that declared it, you're stuck with it.
Well, yes, but that's because you
have you tried
global x2
put 5 into x2
delete global x2
get the globalnames
replace comma with cr in it
put it
i dont see x2 anymore...
-=-
Xavier Bury
Clearstream Services
TNS NT LAN Server
ext 36465
Voice: +352 4656 43 6465
Fax: +352 4656 493
Ken-
Of course, I managed to poke around a bit and get this to happen. I
knew there was *something going on*. Here's the real problem - doesn't
have anything to do with loop indices at all:
Global variables are persistent in memory, even when they've been
purged. Once you have declared a global v
31 matches
Mail list logo
