immediateByteSubclass: ?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

immediateByteSubclass: ?

Stephane Ducasse-3
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
Reply | Threaded
Open this post in threaded view
|

Re: immediateByteSubclass: ?

Clément Béra
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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: immediateByteSubclass: ?

Pharo Smalltalk Developers mailing list
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 <[hidden email]>
To: Pharo Development List <[hidden email]>
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 <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

Re: immediateByteSubclass: ?

Stephane Ducasse-3
Tx we will remove it. 

In pharo 70 we will have 
- a classParser with a class definition to handle all the terrible logic of importing 
- a fluid class definition 
- and it will help removing duplicated and old logic with a huge number of optional parameters
...
Stef

On Fri, May 12, 2017 at 8:25 PM, Benoit St-Jean via Pharo-dev <[hidden email]> wrote:


---------- Forwarded message ----------
From: Benoit St-Jean <[hidden email]>
To: Pharo Development List <[hidden email]>
Cc: 
Bcc: 
Date: Fri, 12 May 2017 18:25:53 +0000 (UTC)
Subject: Re: [Pharo-dev] immediateByteSubclass: ?
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 <[hidden email]>
To: Pharo Development List <[hidden email]>
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 <[hidden email]> 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