Feature Request: CompiledMethod literals should include all selectors and other literals present in the source

1. #Date -> Date
2. #today
3. aDictionary with 3 elements
   
4. anotherDictionary that is empty
5. the source code filePointer

I notice that selectors in compile-time constants and optimized selectors are not accounted for in the CompiledMethod's literals.

20 years ago, the space required to hold the extra references was critical. Now, it is trivial. It is worth the trade-off to be able to effectively use reflection against all methods.


Examples:

junk
    ^##(Dictionary new
            at: 'abc' put: 42;
            at: 'def' put: Object new;
            at: 'ghi' put: 42->Object new;
            yourself)
has exactly one literal, the instance of Dictionary.
There is no association for the class Dictionary nor the selectors #new, #at:put:, and #->.


junk
    ^Date today == 3    "Tuesday"
        ifTrue:
            [##(Dictionary new
                    at: 'abc' put: 42;
                    at: 'def' put: Object new;
                    at: 'ghi' put: 42->Object new;
                    yourself)]
        ifFalse: [##(Dictionary new)]

has a surprising set of literals. There is the expected class association for Date, the selector #today, but only one compile-time constant. I would have expected two Dictionary instances. What happened to the empty Dictionary?
And note that one cannot determine that the method "sends" either #== or #ifTrue:ifFalse:.

Richard -

Compiletime constants are resolved by the compiler and only the result appears in the literals of the CompiledMethod. The content of ##( ) is essentially a DoIt that is discarded after being executed.

I just saved the junk code. When I inspect the CompiledMethod, I see 5 literals:

1. #Date -> Date
2. #today
3. aDictionary with 3 elements
   
4. anotherDictionary that is empty
5. the source code filePointer

John

On Friday, April 17, 2015 at 12:31:58 PM UTC-4, Richard Sargent wrote:

I notice that selectors in compile-time constants and optimized selectors are not accounted for in the CompiledMethod's literals.

20 years ago, the space required to hold the extra references was critical. Now, it is trivial. It is worth the trade-off to be able to effectively use reflection against all methods.


Examples:

junk
    ^##(Dictionary new
            at: 'abc' put: 42;
            at: 'def' put: Object new;
            at: 'ghi' put: 42->Object new;
            yourself)
has exactly one literal, the instance of Dictionary.
There is no association for the class Dictionary nor the selectors #new, #at:put:, and #->.


junk
    ^Date today == 3    "Tuesday"
        ifTrue:
            [##(Dictionary new
                    at: 'abc' put: 42;
                    at: 'def' put: Object new;
                    at: 'ghi' put: 42->Object new;
                    yourself)]
        ifFalse: [##(Dictionary new)]

has a surprising set of literals. There is the expected class association for Date, the selector #today, but only one compile-time constant. I would have expected two Dictionary instances. What happened to the empty Dictionary?
And note that one cannot determine that the method "sends" either #== or #ifTrue:ifFalse:.

On Thursday, September 17, 2015 at 7:35:17 AM UTC-7, John O'Keefe wrote:

Richard -

Compiletime constants are resolved by the compiler and only the result appears in the literals of the CompiledMethod. The content of ##( ) is essentially a DoIt that is discarded after being executed.

That is my complaint. If I refactor code, I don't find senders of methods from CTCs nor references to classes or other literals. This leads to problems and essentially means CTCs are unsafe to use. Hence this feature request.

I just saved the junk code. When I inspect the CompiledMethod, I see 5 literals:

1. #Date -> Date
2. #today
3. aDictionary with 3 elements
   
4. anotherDictionary that is empty
5. the source code filePointer

I must have made a mistake when I examined that one. It should have been there, so I am glad it is.

 

John

On Friday, April 17, 2015 at 12:31:58 PM UTC-4, Richard Sargent wrote:

I notice that selectors in compile-time constants and optimized selectors are not accounted for in the CompiledMethod's literals.

20 years ago, the space required to hold the extra references was critical. Now, it is trivial. It is worth the trade-off to be able to effectively use reflection against all methods.


Examples:

junk
    ^##(Dictionary new
            at: 'abc' put: 42;
            at: 'def' put: Object new;
            at: 'ghi' put: 42->Object new;
            yourself)
has exactly one literal, the instance of Dictionary.
There is no association for the class Dictionary nor the selectors #new, #at:put:, and #->.


junk
    ^Date today == 3    "Tuesday"
        ifTrue:
            [##(Dictionary new
                    at: 'abc' put: 42;
                    at: 'def' put: Object new;
                    at: 'ghi' put: 42->Object new;
                    yourself)]
        ifFalse: [##(Dictionary new)]

has a surprising set of literals. There is the expected class association for Date, the selector #today, but only one compile-time constant. I would have expected two Dictionary instances. What happened to the empty Dictionary?
And note that one cannot determine that the method "sends" either #== or #ifTrue:ifFalse:.

Richard -

Yes, I did recognize what your complaint was - I was trying to explain why it is unlikely that anything will be done about it. Compiletime Constants have never been documented except as an errata to David N. Smith's "IBM Smalltalk" book, and as an explanation of why you can't use them in a server application (we won't tell you what these things are or how to use them, but we'll tell you not to use them). AFAIK there is only one use of Compiletime Constants in the VA Smalltalk code.

John

On Thursday, September 17, 2015 at 12:12:53 PM UTC-4, Richard Sargent wrote:

On Thursday, September 17, 2015 at 7:35:17 AM UTC-7, John O'Keefe wrote:

Richard -

Compiletime constants are resolved by the compiler and only the result appears in the literals of the CompiledMethod. The content of ##( ) is essentially a DoIt that is discarded after being executed.

That is my complaint. If I refactor code, I don't find senders of methods from CTCs nor references to classes or other literals. This leads to problems and essentially means CTCs are unsafe to use. Hence this feature request.

I just saved the junk code. When I inspect the CompiledMethod, I see 5 literals:

1. #Date -> Date
2. #today
3. aDictionary with 3 elements
   
4. anotherDictionary that is empty
5. the source code filePointer

I must have made a mistake when I examined that one. It should have been there, so I am glad it is.

 

John

On Friday, April 17, 2015 at 12:31:58 PM UTC-4, Richard Sargent wrote:

I notice that selectors in compile-time constants and optimized selectors are not accounted for in the CompiledMethod's literals.

20 years ago, the space required to hold the extra references was critical. Now, it is trivial. It is worth the trade-off to be able to effectively use reflection against all methods.


Examples:

junk
    ^##(Dictionary new
            at: 'abc' put: 42;
            at: 'def' put: Object new;
            at: 'ghi' put: 42->Object new;
            yourself)
has exactly one literal, the instance of Dictionary.
There is no association for the class Dictionary nor the selectors #new, #at:put:, and #->.


junk
    ^Date today == 3    "Tuesday"
        ifTrue:
            [##(Dictionary new
                    at: 'abc' put: 42;
                    at: 'def' put: Object new;
                    at: 'ghi' put: 42->Object new;
                    yourself)]
        ifFalse: [##(Dictionary new)]

has a surprising set of literals. There is the expected class association for Date, the selector #today, but only one compile-time constant. I would have expected two Dictionary instances. What happened to the empty Dictionary?
And note that one cannot determine that the method "sends" either #== or #ifTrue:ifFalse:.