If that's of any help, I was able to track it back to Squeak 5.0 and it had no sender in that version too! The author's initials are eem.

-----------------
Beno��t St-Jean
Yahoo! Messenger: bstjean
Twitter: @BenLeChialeux
Pinterest: benoitstjean
Instagram: Chef_Benito
IRC: lamneth
Blogue: endormitoire.wordpress.com
"A standpoint is an intellectual horizon of radius zero". (A. Einstein)

From: Cl��ment Bera <bera.clement@gmail.com>
To: Pharo Development List <pharo-dev@lists.pharo.org>
Sent: Friday, May 12, 2017 1:40 PM
Subject: Re: [Pharo-dev] immediateByteSubclass: ?

This one looks strange and seems indeed to be dead code.

Maybe it was an attempt to make a specific class definition keyword for CompiledMethod / CompiledCode / CompiledBlock. Right now there is a specific case in the code somewhere to use the specific compiledCode layout for those 3 classes instead of the byte layout which is normally used for the keyword variableByteSubclass: that those 3 classes use.

I am not sure immediateByteSubclass: makes sense though. I would rather have compiledCodeSubclass, variablePointerAndByteSubclass or something like that.

On Fri, May 12, 2017 at 5:39 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:

Hi

with guille we are working on a class parser and our game is to make sure that we can parse all the crazy class definitions among which

variableWordSubclass:
ephemeronSubclass:
weakSubclass:
variableByteSubclass:
variableSubclass:
immediateSubclass:
subclass: aSubclassSymbol layout:

And we found this method definition and it has no senders and we wonder if
it is just plain deadcode?

immediateByteSubclass: className instanceVariableNames: instvarNames classVariableNames: classVarNames package: package
"Added to allow for a simplified subclass creation experience. "

^ self
immediateSubclass: className
instanceVariableNames: instvarNames
classVariableNames: classVarNames
package: package

S & G