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