You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There's a question of priority for handling globals, and whether SOM has any names that are special.
nil, true, and false are very basic literals, and allowing them to be changed with System>>global:put: would be consistent with allowing Object>>become: on any object, but seems unnecessary cannon to shoot ones foot off.
Thus, my current preference is to have them simple keyword-like names, which are bound to the expected object.
Other globals, including system, classes names, etc, should be just globals that can be updated.
One could argue that this is an unnecessary complication, and there should not be any special handling of nil, true, and false, because it introduces a new concept, and needs an extra step in parser/implementations, and simply because it is inconsistent.
Still, I am currently leaning towards handling them special to match with what I assume a standard expectation is.
The text was updated successfully, but these errors were encountered:
smarr
added
the
spec
Needs specification, or is specification related.
label
Feb 1, 2020
There's a question of priority for handling globals, and whether SOM has any names that are special.
nil
,true
, andfalse
are very basic literals, and allowing them to be changed withSystem>>global:put:
would be consistent with allowingObject>>become:
on any object, but seems unnecessary cannon to shoot ones foot off.Thus, my current preference is to have them simple keyword-like names, which are bound to the expected object.
Other globals, including
system
, classes names, etc, should be just globals that can be updated.As discussed here:
softdevteam/yksom#90 (comment)
One could argue that this is an unnecessary complication, and there should not be any special handling of
nil
,true
, andfalse
, because it introduces a new concept, and needs an extra step in parser/implementations, and simply because it is inconsistent.Still, I am currently leaning towards handling them special to match with what I assume a standard expectation is.
The text was updated successfully, but these errors were encountered: