[bug] Class variables only bound in methods following them

Issue status update for
http://smalltalk.gnu.org/node/286
Post a follow up:
http://smalltalk.gnu.org/project/comments/add/286

 Project:      GNU Smalltalk
 Version:      <none>
 Component:    VM
 Category:     bug reports
 Priority:     normal
 Assigned to:  Unassigned
 Reported by:  dpollet
 Updated by:   dpollet
 Status:       active

Might be by design, but it's confusing… I suppose the first B resolves
to a non-existent global ?


Object subclass: Fail [
    a [ stdout << 'a:' << B; nl ]
    B := 'hi there'.
    c [ stdout << 'c:' << B; nl ]
]

st> Fail new a; c
a:nil
c:hi there
a Fail
st>





_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Issue status update for
http://smalltalk.gnu.org/project/issue/286
Post a follow up:
http://smalltalk.gnu.org/project/comments/add/286

 Project:      GNU Smalltalk
 Version:      <none>
 Component:    VM
 Category:     bug reports
 Priority:     normal
 Assigned to:  Unassigned
 Reported by:  dpollet
 Updated by:   bonzinip
 Status:       active

I agree that it's confusing, but "stealing" a binding from Undeclared
would not be possible for two reasons:


    *  you risk introducing a binding from one class to another



    *  you cannot handle the case in which two different classes have
the same undeclared variable, and then the variable turns out to be a
class variable /only in one of the two/.


The way to fix this would be to give a warning upon defining the class
variable if the variable can be found in Undeclared.  Usually the
naming conventions for globals and class variables are different enough
that it should not give many false positives.




_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Issue status update for
http://smalltalk.gnu.org/project/issue/286
Post a follow up:
http://smalltalk.gnu.org/project/comments/add/286

 Project:      GNU Smalltalk
 Version:      <none>
 Component:    VM
 Category:     bug reports
 Priority:     normal
 Assigned to:  Unassigned
 Reported by:  dpollet
 Updated by:   dpollet
 Status:       active

What about going through the class definition for class variables first,
then compile the methods? So at least inside the A subclass: B [ … ]
block, the compiler would only "Undeclare" only what's really not
there.




_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Issue status update for
http://smalltalk.gnu.org/project/issue/286
Post a follow up:
http://smalltalk.gnu.org/project/comments/add/286

 Project:      GNU Smalltalk
 Version:      <none>
 Component:    VM
 Category:     bug reports
 Priority:     normal
 Assigned to:  Unassigned
 Reported by:  dpollet
 Updated by:   bonzinip
 Status:       active

That would mean you have to keep potentially the entire class in memory,
right?  Right now the parse tree of GNU Smalltalk is never deeper than a
method.




_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Issue status update for
http://smalltalk.gnu.org/project/issue/286
Post a follow up:
http://smalltalk.gnu.org/project/comments/add/286

 Project:      GNU Smalltalk
 Version:      <none>
 Component:    VM
 Category:     bug reports
 Priority:     normal
 Assigned to:  Unassigned
 Reported by:  dpollet
 Updated by:   dpollet
 Status:       active

Indeed. I'm thinking like in pure file-based languages where you want to
organize the file arbitrarily and use lexical scope. I'm not entirely
clear how variable pools are resolved in other Smalltalks anyway. Here
class variables just seemed like a nice way to emulate constants for
synopsis, help text, and so on :)




_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Issue status update for
http://smalltalk.gnu.org/project/issue/286
Post a follow up:
http://smalltalk.gnu.org/project/comments/add/286

 Project:      GNU Smalltalk
 Version:      <none>
 Component:    VM
 Category:     bug reports
 Priority:     normal
 Assigned to:  Unassigned
 Reported by:  dpollet
 Updated by:   bonzinip
-Status:       active
+Status:       invalid

> Here class variables just seemed like a nice way to emulate constants
for synopsis, help text, and so on :)

Yes, you just have to place them before they're used. :-)

Ruby and Python behave like this too, I think it is safe to declare
this invalid.

Thanks for raising the point anyway!




_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Issue status update for
http://smalltalk.gnu.org/project/issue/286
Post a follow up:
http://smalltalk.gnu.org/project/comments/add/286

 Project:      GNU Smalltalk
 Version:      <none>
 Component:    VM
 Category:     bug reports
 Priority:     normal
 Assigned to:  Unassigned
 Reported by:  dpollet
 Updated by:   dpollet
-Status:       invalid
+Status:       active

Actually, ruby behaves like I want:
   def hello
     puts HELLO
   end
   # calling hello would fail here
   HELLO = "Hello, world!"
   hello()

the variable is bound like it should even if the reference is before
the declaration (well actually it's declared when it's first seen in
the method), but of course if you evaluate it before it's been
initialized, then you get an exception.




_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Issue status update for
http://smalltalk.gnu.org/project/issue/286
Post a follow up:
http://smalltalk.gnu.org/project/comments/add/286

 Project:      GNU Smalltalk
 Version:      <none>
 Component:    VM
 Category:     bug reports
 Priority:     normal
 Assigned to:  Unassigned
 Reported by:  dpollet
 Updated by:   bonzinip
-Status:       active
+Status:       postponed

Given that Ruby is also a bit inconsistent, I'll leave the bug in the
database, but I don't plan about working on it anytime soon.




_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Issue status update for
http://smalltalk.gnu.org/project/issue/286
Post a follow up:
http://smalltalk.gnu.org/project/comments/add/286

 Project:      GNU Smalltalk
 Version:      <none>
 Component:    VM
 Category:     bug reports
 Priority:     normal
 Assigned to:  Unassigned
 Reported by:  dpollet
 Updated by:   zecke
-Status:       postponed
+Status:       active

Can we close it? I don't think we will implement it and with the other
fileout syntaxes one needs to declare the class variable early as well?



_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

Issue status update for
http://smalltalk.gnu.org/project/issue/286
Post a follow up:
http://smalltalk.gnu.org/project/comments/add/286

 Project:      GNU Smalltalk
 Version:      <none>
 Component:    VM
 Category:     bug reports
 Priority:     normal
 Assigned to:  Unassigned
 Reported by:  dpollet
 Updated by:   bonzinip
-Status:       active
+Status:       won't fix

We could force the class variables to come before any method.  That
would still have problems in the "extend" case.

I also thought about restricting the grammar to have a constant on the
right side.  This would simplify exporting to other dialects.  However,
there is really no restriction because you can use ##(...) to treat
anything as a constant.

So in the end it is really a case of "if it hurts, don't do it"...



_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk