The script variable from the custom block is not working properly.
(Thought it would report 7)
But using Python works:
(Actually reports 7)
This problem needs to be fixed.
Snap is not the same as python, so you shouldn’t be comparing the different behaviors.
I think I know what’s happening. I think when you put rings in objects (which in snap is just a key/value pair list), the context is lost, so any variables outside the ring would not work.
I agree, but this problem needs to be fixed to become compatible with other languages…
???
I am 120% sure Snap! does not even endorse this Python thing in the first place. Nothing is designed to be compatible with everything.
if you want snap to interpret other languages you add that yourself, it’s not Jens job to maintain other languages, what kind of request is that? Also, that’s rather poorly worded in my opinion. Comes off rude and demanding.
I absolutely want a proper c interpreter, but I’m not asking Jens to implement it for me. That’s entirely up to me (It’ll never happen)
In your case, you are using a variable to capture a reference to yourself. Instead of using the MANIPULATOR variable, you should use THIS OBJECT.
Snap is not trying to be compatible with other languages, it is a language. Why should it be compatible?
From Snap! v12 Beta test
I was making an RPN parser but I abandoned the project becuase of that bug. It needs to be compatible to make properly.
It’s not a bug, and please stop thinking that way.
Any program can be written in any Turing-equivalent language. That is, any program that can be written in Python can be written in Snap!. But if you want to use a language effectively, you have to learn to think in that language, not think in some other language and try to translate mechanically.
It’s the same with human languages. In high school I studied French, and at first, as beginners always do, I thought in English and tried to translate word by word into French. The result was sometimes comprehensible to a French speaker, but nobody would ever have mistaken me for a French speaker at that point. Eventually, after a couple of years of study, one day I suddenly found myself thinking in French. That doesn’t mean my own French was suddenly perfect, but it was a lot better! And when, as a beginner, I came across some French idiom that was very different from the way it would be expressed in English, it would have been really arrogant of me to declare that French has a bug in it because it’s different from English! Since I know you’re (at least) bilingual (in human languages) I’m sure you’ve had similar experiences.
You can write your RPN parser in Snap! if you want to. You just have to write it in Snap!, not just write it in Python and transliterate.
It would do you a lot of good, I think, to learn a programming language such as Prolog that’s very different from what you’re accustomed to.
As for the question of why Snap! behaves this way, Jens points out correctly that if you represent an object using a dictionary, the methods in the dictionary need access to the fields of the object. He reminds me that methods use this special scope rule only when accessed by keyword:
I still hope to persuade him that even when accessed by keyword, the method should have access to the object’s scope and its own lexical scope. But not until he’s back from vacation. :~)
I know, I know, don’t respond to yourself.
But I’m wondering if anyone can tell me why that error message doesn’t show a green oval behind the _ + NUM text?
Probably for the same reason that continuations lack the green oval. The container of “num” is not the + block but the variadic input itself.
You might notice that the picture above cannot be created in Snap 12. That is because continuations error when capturing a variadic input (this is a bug I will be reporting in a new thread).
Edit: Actually, they only error when trying to display a captured variadic input (when visible stepping shows intermediate results, when showing result balloons, or when displaying speech balloons). Variable watchers make Snap lag heavily rather than error.
As for the actual “bug” discussed in this topic, a recommendation for @onu032001: instead of naming the topic “A big problem in Snap!”, name it something more descriptive and less misleading like “OOP loses access to script variables.”
The reason why the current title is misleading is because it sounds like you’re describing an urgent issue like a crash or other fundamental failure. I recognize that English isn’t your first language, so that may have played a hand in this. I’m not blaming you, just giving you a heads up.
To solve your actual problem, it might be helpful to load the OOP library and use that, since it provides the function you were trying to do but much easier.
However, one thing I will say about the OOP library, is that there’s only a block to get values, none to just call a function that doesn’t expect a return value. I also noticed that the field input of the field block does not seem to detect the fields in this object because it’s not placed directly in second slot, so it throws an error when you edit the field input.
Side note
I would actually not even write that python code like that. I would instead do something like this
class Mutator:
value: int = 0
def mutate(self):
self.value += 1
test = Mutator()
for i in range(3):
test.mutate()
print(test.value) # 3
Which is actually pretty similar to the way I showed how to do it in snap.
Probably for the same reason that continuations lack the green oval. The container of “num” is not the + block but the variadic input itself.
Oh. But, the continuation of an expression isn’t just its immediate container; it’s the entire rest of the computation waiting to be performed. So I think the picture should still have a green background.
I wish I could say that English has a couple of bugs that annoy me so much. And no, I will not say it is because of another language that it caused this.
What's wrong with replying to oneself (I am just curious)? Lack of conformance to an unspoken rule in the etiquette? Too many profile pictures of oneself cluttering the topic? Narcissism?
Oh, well, all languages have annoyances, English definitely included. All the different ways to pronounce “-ough,” for example. (In French it’s almost the case that you can deduce a word’s pronunciation from its spelling, which is much better, but then you come across Aix-en-Provence.)
What’s wrong with replying to oneself (I am just curious)? Lack of conformance to an unspoken rule in the etiquette? Too many profile pictures of oneself cluttering the topic? Narcissism?
I dunno, just that people always yell at each other for doing it.
It’s mainly annoying in cases like this:
"do you know how the _____ works?
reply to self: also ______ isn’t working
reply again: @sathvikrias @\ego-lay_atman-bay help me please
reply again: ok nevermind I fixed it myself but I still need help with my other project
"