Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Unable to create instance variables in a block. #105
Turns out that this is rather more difficult to do than one might realize. Why?
Currently, when an instance variable is created, a method is defined against the receiver of the current method definition. In a block there is no such receiver at the time the code is being compiled. In fact, the context contains very little at all:
Note that there is no receiver, object or class at all.
At run time, there is the self value. That's about it. Some serious rethink is needed about
Let's look at some options here. There are a bunch of them!
This will allow instance variables to be created in procedures, but will create a "wild west" of variables. When undeclared variables are referenced, there will be no error, just a poison nil value. This is pretty ugly.
This will allow instance variables to be created anywhere, but will create a "wild wild wild west" of variables. When undeclared variables are referenced, there will be no error, just a poison nil value. This is even uglier.
4,5) Make instance variables self routed methods and make that the default in either procedures or globally. Further, add the method at run time. This will generate a runtime error for an undeclared variable. not as good as a compiler error but better than nil value poison. These methods will however be slower than the current embedded code approach.
With the introspect update we get more details:
After a very long delay, some fresh ideas on this topic.
What if val@: and var@: in a procedure were immediate methods that did two things:
True, in other procedures these variables would be unavailable, but that's OK. Those other procedure have no connection to the object that the creating procedure used.